1 : Centre national des oeuvres universitaires et scolaires Ministère de l'Enseignement Supérieur et de la Recherche Scientifique
Contexte Le réseau des CROUS (Centres Régionaux des Œuvres Universitaires et Scolaires) assure la restauration des étudiants à travers ses 26 centres répartis sur l'ensemble du territoire français, de l'Hexagone jusqu'aux territoires ultramarins : Réunion, Guyane et Antilles. Cette organisation génère un volume important de transactions : Plus de 2000 points de ventes produisent chaque année plus de 66 millions de tickets de caisse, un chiffre en constante augmentation depuis l'instauration du repas à 1€ pour les étudiants boursiers. Au-delà du volume important, les besoins fonctionnels évoluent rapidement : La gestion des stocks en temps réel devient incontournable : connaître instantanément le nombre de sandwichs restants dans une cafétéria permet d'optimiser le réapprovisionnement et de limiter le gaspillage. Les exigences en matière d'infocentre augmentes également ce qui impose une centralisation des données historiquement dispersées dans chaque CROUS. Génération 1 : l'ère du fichier plat (avant 2019) L'architecture initiale reposait sur un modèle entièrement décentralisé : Chaque caisse produisait des fichiers plats chiffrés et déposés sur des serveurs FTP locaux à chaque CROUS. Des traitements batch récupéraient ensuite ces fichiers pour les intégrer dans les bases de données locales. Cette approche présentait l'avantage d'un faible couplage et d'une charge limitée sur les infrastructures : chaque caisse écrivait ses fichiers lors de la clôture et les batchs importaient les données séquentiellement. En revanche, elle impliquait une forte complexité opérationnelle, avec des serveurs FTP et des ordonnanceurs de traitements batch à maintenir dans chacun des 26 CROUS. Les données n'étaient disponibles qu'en différé, rendant impossible toute exploitation en temps réel, notamment pour la gestion des stocks. Le risque de corruption ou de perte de fichiers généraient par ailleurs une charge de support significative aux niveaux national et régional. Génération 2 : l'API REST centralisée (2019-2025) Pour répondre aux nouveaux besoins et simplifier l'architecture, une API REST centralisée a été mise en place en 2019. L'objectif initial visait à permettre aux caisses d'écrire directement dans les 27 bases de données via une API unique. La réalité technique a rapidement imposé des compromis. Les déconnexions fréquentes des bases de données (surtout dans les Crous ultramarins) ont conduit à revoir l'architecture : les tickets sont désormais écrits dans une base centrale, puis répliqués vers les bases locales de chaque CROUS via des jobs Talend. L'infrastructure s'est simplifiée avec la disparition des serveurs FTP, mais de nouvelles contraintes sont apparues. Les traitements Talend s'exécutent toutes les cinq minutes pour donner une illusion de temps réel, ce qui ajoute une couche de complexité opérationnelle. La duplication des données impose des mécanismes de purge réguliers et surtout, la concentration des écritures entre 12h00 et 13h00, période de forte affluence dans les restaurants universitaires, a nécessité un surdimensionnement de la base de données. Une tentative d'implémentation de la gestion des stocks par des webhooks n'a pas été retenue car l'API ne parvenait pas à réaliser simultanément les insertions massives de tickets et les appels HTTP sortants vers les systèmes de stock. Le couplage synchrone montrait ses limites. Génération 3 : l'event-driven avec Kafka et Gravitee (2026) La troisième génération d'architecture, en cours de déploiement, adopte le paradigme event-driven grâce à Apache Kafka. L'élément essentiel de cette migration est l'utilisation de Gravitee pour faire de la médiation de protocole : le logiciel de caisse continue d'effectuer des requêtes HTTP vers une API REST, sans aucune modification, ni implémentation d'un protocole complexe, ni nécessité d'ouverture de ports tcp supplémentaire. Gravitee traite ces requêtes et publie les messages correspondants dans les topics Kafka. Cette approche offre plusieurs avantages majeurs. Le découplage entre producteurs et consommateurs absorbe naturellement les pics de charge du midi. Kafka assure nativement la persistance des messages et permet leur rejeu en cas de défaillance d'un consommateur : un incident sur une base CROUS n'entraîne plus de perte de données, contrairement au modèle synchrone précédent. Des consommateurs dédiés récupèrent les tickets pour les insérer dans les bases de chaque CROUS, chacun à son rythme. La gestion des stocks devient possible grâce à des consommateurs spécialisés, sans impacter la chaîne principale d'insertion. Les événements techniques, auparavant stockés en base de données relationnelle, sont désormais routés vers Elasticsearch via Logstash, constituant un puits de logs adapté à leur nature. Le pattern « un événement, plusieurs consommateurs » permet d'envisager sereinement l'ajout de nouveaux cas d'usage : analytics temps réel, alerting, alimentation de systèmes tiers, sans jamais modifier la chaîne de production des événements. L'augmentation du nombre de points de vente, portée par le développement de dispositifs tels que les distributeurs automatiques de repas ou les frigos connectés, peut ainsi être envisagée de manière sereine. Enseignements et perspectives Ce retour d'expérience illustre une trajectoire de modernisation progressive d'un SI national sur quinze ans. Chaque génération a répondu aux contraintes et architecture “mainstream” de son époque tout en révélant de nouvelles limites. Le passage à l'event-driven ne constitue pas une rupture brutale mais une évolution rendue possible par la médiation protocolaire. Les systèmes legacy continuent de fonctionner pendant que l'architecture sous-jacente se transforme. Gravitee joue un rôle clé en masquant la complexité de Kafka aux caisses, permettant une migration simplifiée. Les prochains objectifs concernent l'exploitation des capacités de Kafka Streams pour produire des indicateurs en temps réel et l'extension du modèle événementiel à d'autres flux du SI des CROUS.
Type :
:
Présentation
Thématiques
:
La programmation d’aujourd’hui et de demain
