Juin 2026 · 7 min de lecture
Comment livrer un logiciel où tout le risque est dans la plomberie, SSO Microsoft, add-in Outlook, et en sortir des données d'annotation dignes de confiance.
Sur le papier, le projet avait l'air sage : un petit volet dans Outlook pour étiqueter des e-mails avec des catégories métier, et un tableau de bord pour les administrateurs. Des cases à cocher, une table en base, quelques graphiques. Rien d'effrayant.
Sauf que le vrai risque n'était pas là.
Les formulaires et les tables, on sait les écrire. Ce qu'on ne peut pas vérifier tant que tout ne tourne pas ensemble, c'est la plomberie d'intégration : un jeton SSO obtenu silencieusement par un add-in Office, transmis à un backend qui doit le valider cryptographiquement, le tout dans une vraie boîte Outlook : sur le web comme sur le bureau. Tant que ces pièces ne dialoguent pas pour de vrai, on ne sait pas si le projet est faisable. On l'espère.
La tentation, dans ces cas-là, c'est de repousser l'intégration : « on branchera l'authentification à la fin, quand le reste sera prêt ». C'est exactement l'inverse qu'il faut faire.
Nous avons construit un squelette qui marche (« walking skeleton ») avant toute fonctionnalité : le plus petit chemin de bout en bout qui prouve que la chaîne tient. L'add-in se charge dans Outlook, obtient un jeton, appelle le backend, le backend le valide, répond. Rien d'utile pour l'utilisateur à ce stade, mais la partie risquée est démontrée vivante.
Une fois ce fil prouvé, tout le reste s'y accroche par petites touches : les catégories, l'enregistrement, l'épinglage du volet, les statistiques. Chaque ajout est incrémental, posé sur une base déjà vérifiée. Aucune mauvaise surprise gardée pour la fin.
La leçon n'est pas nouvelle, mais elle se mérite à chaque projet : livrez d'abord ce qui fait peur. Le morceau incertain doit être le premier à toucher la réalité, pas le dernier.
Le backend est en Python, les deux interfaces (le plugin et le tableau de bord) sont en TypeScript. À cette frontière entre deux langages, les types ont une fâcheuse tendance à diverger en silence : le serveur renomme un champ, les interfaces ne le savent pas, et le bug n'apparaît qu'à l'exécution, chez l'utilisateur.
Nous avons supprimé ce risque en faisant du schéma OpenAPI du backend la source de vérité unique : les types TypeScript des interfaces en sont générés. Si un contrat change côté serveur sans être répercuté, ce n'est plus un bug discret en production, c'est une erreur de compilation, tout de suite, sur le poste du développeur.
Faire d'une catégorie entière de bugs une impossibilité, plutôt qu'une vigilance, change la sérénité d'une équipe.
L'objectif analytique du projet est subtil : faire annoter les mêmes e-mails par plusieurs personnes, puis mesurer à quel point elles sont d'accord. C'est ce qui permet de savoir si une taxonomie est claire et si les données qu'on en tire sont dignes de confiance.
Mais cette mesure n'a de sens qu'à une condition : que personne ne voie le travail des autres pendant qu'il annote. Sinon, on copie son voisin sans même s'en rendre compte, et l'accord obtenu ne mesure plus rien.
La garantie est devenue une propriété d'architecture, pas une promesse : le plugin n'émet jamais la moindre requête capable de renvoyer l'annotation d'un autre. Il écrit, il ne lit pas le travail d'autrui. L'accord (calculé par recouvrement des catégories, e-mail par e-mail) est donc honnête par construction, et il révèle, au passage, les catégories ambiguës qui méritent d'être reformulées.
En cours de route, une décision importante s'est inversée. Le système avait été pensé comme pseudonyme : stocker des identifiants opaques, jamais les personnes. Le besoin réel s'est révélé différent : il fallait savoir qui avait annoté quoi. Nous sommes passés à un stockage identifié, assumant que cela manipule des données personnelles, avec les obligations qui vont avec.
Ce qui compte ici n'est pas le revirement, c'est la manière. Le changement a été écrit noir sur blanc dans les spécifications, avec sa justification et ses conséquences (« reversed from pseudonymity »). Une décision qu'on documente, y compris quand elle contredit la précédente, reste discutable et réversible. Une décision qui glisse en silence dans le code devient une dette que plus personne ne comprend six mois plus tard.
Deux détails, invisibles pour l'utilisateur, disent l'état d'esprit du projet.
Le code d'un add-in Office est public : impossible d'y cacher un secret. La sécurité ne repose donc sur aucune clé enfouie, mais sur un point d'ancrage de confiance : des jetons Microsoft validés à chaque écriture (signature, émetteur, audience, expiration).
Et pour travailler confortablement en local, un mode « dev » court-circuite l'authentification. Le piège classique serait qu'il atteigne la production. Le programme refuse tout simplement de démarrer s'il détecte ce mode en environnement de production. Le défaut sûr n'est pas un rappel dans une documentation : c'est un garde-fou dans le code.
Aucune de ces idées n'est spectaculaire. Commencer par le morceau risqué. Rendre les contrats impossibles à enfreindre en silence. Faire des garanties des propriétés d'architecture plutôt que des promesses. Documenter les décisions, surtout quand on en change. Choisir le défaut sûr.
Mises bout à bout, ce sont elles qui font la différence entre un logiciel qu'on espère voir marcher et un logiciel dont on sait pourquoi il marche.
Et accessoirement, c'est aussi ce qui transforme une pile d'e-mails en données sur lesquelles on peut, ensuite, construire en confiance.