Société savante de chirurgie thoracique et cardio-vasculaire. Depuis 2024, je conçois et développe l’interface de l’application de ses congrès — ce que l’utilisateur a sous les yeux : inscriptions, réservation d’hôtel, paiement, dépôt et notation des résumés scientifiques par les pairs. Mission toujours en cours.
Secteur : santé
Période : depuis 2024
Rôle : conception et développement de l’interface ; orientation de l’architecture serveur
Statut : mission en cours
Le contexte
Une société savante fait vivre sa discipline par ses congrès. Des chirurgiens s’y inscrivent, choisissent des options et une chambre d’hôtel, paient, et surtout y soumettent des résumés scientifiques que leurs pairs notent avant sélection.
Chacun de ces objets porte un enjeu qui lui est propre, et ils ne se ressemblent pas. Une inscription est un engagement financier. Une réservation d’hôtel engage un tiers. Un résumé non encore publié est une information confidentielle qui appartient à son auteur. Et une notation par les pairs ne vaut que si personne ne peut voir ce qu’il ne doit pas voir. Construire cette application, ce n’est pas assembler des écrans d’inscription : c’est faire cohabiter quatre régimes de confidentialité dans un même produit, devant un public qui n’a aucune tolérance pour l’à-peu-près et de très bonnes raisons de ne pas en avoir.
Le système vit dans deux dépôts de code, un mainteneur chacun. Je suis le seul auteur humain des 776 modifications enregistrées côté interface depuis mars 2024 — chiffre arrêté au 5 septembre 2026. Le serveur revient à un développeur backend senior : nous concevons les fonctionnalités en binôme, et j’interviens sur ses choix d’architecture sans en écrire le code.
Le périmètre, dit précisément
J’ai conçu et développé l’interface. J’ai orienté les choix d’architecture du serveur sans en écrire le code. La conception des fonctionnalités s’est faite en binôme avec le développeur backend senior qui en est l’auteur.
Cette distinction n’est pas une précaution rédactionnelle, c’est la description exacte du métier. Décider ce qu’un serveur doit garantir, l’écrire, et laisser quelqu’un d’autre le construire demande de savoir formuler une contrainte sans imposer une implémentation — et d’accepter qu’on sera jugé sur la contrainte, pas sur le code. C’est aussi ce qui permet à l’architecture de survivre au départ de celui qui l’a posée.
Les décisions
Spécifier le serveur depuis l’interface, avant qu’il sache répondre.
Une fonctionnalité de planification a réclamé au serveur une capacité qu’il n’avait pas encore. La réaction courante est d’attendre, ou de bricoler côté interface en promettant de nettoyer plus tard ; les deux se paient, la première en calendrier, la seconde en dette.
J’en ai écrit la spécification : ce que le serveur doit renvoyer, l’option que j’écartais — un simple indicateur posé sur les événements existants, qui aurait alourdi toutes les requêtes déjà en place — et la raison de l’écarter. Consigner l’option écartée avec son motif n’est pas de la documentation de confort : un choix dont on n’a gardé que le résultat n’est plus un choix six mois plus tard, c’est une convention que personne n’ose remettre en question parce que personne ne sait plus ce qu’elle a coûté.
En attendant, l’interface interroge le serveur au chargement. Tant qu’il ne connaît pas cette fonction, elle reste masquée sans laisser de trou dans l’écran, et elle s’activera seule le jour où il la publiera. Conséquence concrète : aucune mise en ligne à synchroniser entre les deux dépôts, donc aucune fenêtre où l’un livre à moitié en attendant l’autre. C’est ce qui permet à deux dépôts tenus par deux mainteneurs de rester chacun cohérent.
Traiter une licence payante comme une vérification, jamais comme une déclaration.
Les composants de tableaux, de graphiques et de calendrier sont sous contrat commercial. Une clé sortie de sa fenêtre de validité a déjà fait apparaître un bandeau « licence expirée » par-dessus l’interface. Ce n’est pas une panne technique : c’est un bandeau d’impayé posé par-dessus une application de santé, que le client subit à la place de son fournisseur.
Ces composants sont désormais figés à la version exacte, et l’installation est refusée si ce qui s’installe ne correspond pas à ce qui est enregistré. À côté, une liste écrite recense les licences autorisées — treize — les licences interdites — douze — et trente-deux exceptions, chacune motivée et datée. Un script la contrôle et échoue au moindre écart.
L’exception datée mérite qu’on s’y arrête. Une exception sans date est une porte ouverte définitivement pour une raison qu’on a oubliée. Avec sa date et son motif, elle redevient une décision qu’on peut réexaminer, et le jour où on la réexamine, on sait ce qu’on avait accepté.
Rendre un canal incapable de transporter une donnée de santé.
Quand une erreur survient dans une application, le navigateur envoie automatiquement un rapport à un service extérieur pour qu’on puisse la corriger. Par défaut, ces rapports emportent volontiers l’identité de la personne connectée et le contenu de son écran. C’est un canal de fuite qui ne ressemble pas à un canal de fuite : personne ne l’inspecte, parce que personne ne le considère comme une fonctionnalité.
Ici, les rapports partent sans identifiant de connexion, réduits à cinq indicateurs. Ni nom, ni adresse électronique, ni donnée médicale, ni jeton d’accès n’y figurent. On perd un peu de confort de diagnostic ; on gagne l’assurance que ce canal ne peut pas transporter ce qu’il ne doit pas transporter, indépendamment de ce que quelqu’un y ajoutera l’an prochain.
Deuxième point, plus banal et plus fréquent : les envois groupés depuis les tableaux de congressistes mettent les destinataires en copie cachée. La fuite ordinaire n’est pas une intrusion, c’est une liste de participants en clair dans un message que quelqu’un transfère.
Ce qui n’est pas verrouillé
Le verrouillage des versions de composants est automatique : il s’applique avant chaque mise en ligne, sans que personne ait à y penser. Le contrôle de la liste des licences, lui, se lance à la demande. Ce ne sont pas deux garanties de même nature, et je ne les présente pas comme telles. Tant que ce contrôle n’est pas déclenché à chaque proposition de modification du code, une dépendance sous licence interdite peut entrer sans que rien ne s’y oppose sur le moment. C’est écrit ici parce que c’est vrai, et parce que c’est exactement le genre d’écart qu’un audit doit produire : non pas « il y a un problème », mais « voici la règle, voici où elle est tenue par la machine, voici où elle repose encore sur quelqu’un ».
LE PRINCIPE DIRECTEUR
Je pars du principe que je peux oublier. Ce qui protège un patient ou un contrat est donc placé là où l’oubli est refusé par la machine, pas là où il se remarque après coup.
La stack
React, TypeScript, Vite, Redux Toolkit et RTK Query, MUI et MUI X Premium, Sentry, Vitest, GitHub Actions, devant une API Django REST sur PostgreSQL tenue par mon binôme.
Ce qu’en disent le client et mon binôme
« Il s’est approprié nos enjeux avec discernement […] le tout en sachant anticiper nos besoins et proposer des solutions éclairées. »
— Directrice, SFCTCV
« Excellentes compétences en dev web, architecture et IA. Il apporte une vraie vision produit axée sur l’UX. »
— Renaud D., développeur backend senior sur le projet
L’ÉTAPE SUIVANTE
Si votre situation ressemble à celle-ci — un système en service, des règles métier qui doivent tenir, et le besoin de savoir lesquelles tiennent réellement aujourd’hui — c’est l’audit de trois jours qui répond. Il dit où vous en êtes, dans quel ordre traiter, et ce que coûte chaque report ; la remise en état vient ensuite.
Audit de codebase généré par IA : ce qui tient, ce qui doit être repris — 3 jours, 2 400 € HT
Nous utilisons des cookies uniquement pour le bon fonctionnement du site. Avec votre accord, nous activons aussi le module de prise de rendez-vous Calendly, qui dépose ses propres cookies. Vous pouvez changer d’avis à tout moment depuis le pied de page. En savoir plus
