Je ne nommerai pas le client : l'engagement de confidentialité est la première règle d'une mission en régie, et elle prime sur toute envie de faire un beau cas client. Ce que je peux partager, en revanche, c'est le retour d'ingénierie - les choix d'architecture, les blocages, la méthode. C'est un secteur qui gagne à être documenté : l'enseignement supérieur privé, avec ses contraintes propres.

Le contexte : deux plateformes, un même établissement

Deux chantiers en parallèle. Un portail étudiant à moderniser, utilisé au quotidien par plusieurs milliers de comptes actifs. Et une application de mise en relation entre candidats et entreprises, construite autour du traitement de curriculum vitæ et pensée pour l'intelligence artificielle dès la conception - pas ajoutée après coup en couche cosmétique.

Pourquoi un BFF, et pas un appel direct

Un back-for-front, c'est une couche serveur dédiée à un front-end donné, qui n'expose au client que ce dont ce front a besoin - ni plus, ni moins. Sur un portail étudiant qui agrège plusieurs systèmes d'information hérités, c'est ce qui évite au navigateur de devoir connaître l'existence de trois API différentes, chacune avec son format, son authentification, ses pannes propres.

Le BFF absorbe cette hétérogénéité. Il expose un contrat stable au front, pendant que les systèmes en amont continuent d'évoluer à leur rythme - parfois plus lentement que souhaité, ce qui est précisément la réalité d'un système d'information en établissement d'enseignement.

Sécuriser l'authentification sans casser l'existant

La sécurisation d'authentification sur un système déjà en production impose une contrainte que l'on n'a pas sur un projet neuf : chaque changement doit rester rétrocompatible pour les sessions actives, le temps que la bascule se fasse proprement. On ne coupe pas un portail utilisé par des milliers d'étudiants un lundi matin pour changer de mécanisme de jetons.

Le matching de compétences, pensé IA dès la conception

L'application de mise en relation candidats-entreprises traite des curriculum vitæ pour en extraire des compétences, et les rapprocher des besoins exprimés par les entreprises partenaires. La différence entre un prototype qui impressionne en démonstration et un système qui tient en production, c'est la gestion des cas limites : un CV mal formaté, une compétence formulée différemment d'une entreprise à l'autre, un candidat qui ne rentre dans aucune case prévue.

Traiter ces cas correctement demande moins de génie algorithmique que de rigueur d'ingénierie : validation systématique des données en entrée, revue humaine des correspondances à faible confiance, traçabilité de chaque décision de matching pour pouvoir l'expliquer si nécessaire.

Ce que la chaîne d'intégration continue a révélé

Une partie du travail a consisté à corriger une chaîne d'intégration continue qui échouait de façon intermittente - le pire genre de panne, parce qu'elle érode la confiance de l'équipe dans ses propres outils avant même de bloquer une livraison. La cause tenait à des dépendances de tests mal isolées, qui laissaient un test précédent influencer le suivant selon l'ordre d'exécution. Une fois identifiée, la correction était simple. La trouver a demandé de la méthode, pas de la chance.

Ce que ça change pour mes clients locaux

Ce qu'on apprend sur une plateforme à fort trafic - rigueur d'architecture, discipline de tests, exigence de sécurité - se réinvestit intégralement chez un commerçant ou un artisan des Yvelines, même quand le projet est cent fois plus modeste. Un site vitrine bien construit et une plateforme d'enseignement supérieur partagent la même exigence de base : ne jamais faire porter au client final la dette technique d'un raccourci pris en cours de route.