Décisions d'architecture, dette assumée, pièges d'un système : une mémoire technique qui part avec les développeurs qui l'ont bâti.
Éditeurs, ESN et DSI, de 10 à 500 personnes.
Le code est versionné, les tests passent, la documentation existe. Ce qui part, c'est la raison pour laquelle le système est fait ainsi, et elle n'est dans aucun commit.
Architecture
Pourquoi Kubernetes a été abandonné en 2019 au profit d'une autre orchestration, quelle latence supplémentaire avait été mesurée. Sans cette trace, l'équipe suivante refait le même essai, obtient le même résultat, et perd le même trimestre.
Règles métier
Une règle d'arrondi spécifique enfouie dans une fonction utilitaire, écrite un jour pour satisfaire une exigence comptable réelle. Personne ne sait plus laquelle. Personne n'ose donc y toucher, et personne ne peut la valider.
Exploitation
Un script hérité qui tourne chaque nuit, extrait les comptes modifiés et les pousse vers un système ancien. Un redémarrage nocturne qui masque une fuite chronique depuis des années. Tout marche, jusqu'au jour où la personne qui savait n'est plus là.
Cession
En due diligence technique, la concentration du savoir sur une ou deux têtes est un point de négociation direct sur le prix. Elle se mesure, et elle se corrige avant, pas pendant.
65 %
Des projets logiciels majeurs sont vulnérables au départ d'un ou deux contributeurs. Ce n'est pas une exception d'organisation, c'est la norme.
Étude académique sur 133 projets GitHub
Ces quatre pertes ne se paient ni au même moment ni au même prix. Voici comment les hiérarchiser.
Ce tableau se remplit en une réunion d'équipe. Vous en sortez avec la liste des zones où le départ d'une personne bloquerait la production, dans l'ordre. Il vous appartient, même si nous n'allons pas plus loin ensemble.
| Critère | Porté par | Documenté | Coût si la personne part |
|---|---|---|---|
| Raisons derrière les choix d'architecture | Un à deux développeurs historiques | Code, sans les motifs | Réécriture d'un système qui marchait |
| Zones fragiles du système | Deux personnes | Non | Incident en production |
| Dettes techniques assumées et leurs échéances | Le lead technique | Tickets épars | La dette explose au pire moment |
| Contraintes métier encodées sans commentaire | Personne, en pratique | Non | Règles de gestion perdues avec le code |
Raisons derrière les choix d'architecture
Zones fragiles du système
Dettes techniques assumées et leurs échéances
Contraintes métier encodées sans commentaire
Les entretiens sont menés par quelqu'un qui a développé et exploité. C'est ce qui permet de relancer sur une décision d'architecture qu'un lead juge trop évidente pour l'expliquer, et de comprendre un contournement sans le juger.
Avant
Nous listons avec vous les personnes à interroger et les sujets à écarter : les clés, identifiants et secrets d'infrastructure, les données de production, le code sous licence tierce restrictive. Vous validez ce périmètre avant le premier entretien.
Pendant
Écran partagé, sur le dépôt réel plutôt que sur un schéma d'intention, sur plusieurs séances. La personne montre autant qu'elle explique, et l'expert relance sur ce qu'elle a sauté parce que cela lui paraissait évident.
Ensuite
Vos décisions d'architecture et vos post-mortems existent déjà, mais personne ne sait lequel s'applique à quel cas. Ils sont rattachés aux explications qui leur donnent leur sens, au lieu de rester rangés à côté.
À la fin
Rien n'est mis à disposition de vos équipes sans son accord. C'est la condition pour qu'elle parle librement pendant les entretiens, et c'est ce qui sépare un recueil d'un contrôle.
Une fois les entretiens terminés, voici ce qu'un développeur qui arrive a devant lui.
Le patrimoine, c'est l'outil interne qui contient leurs réponses et vos documents techniques, et que vos développeurs interrogent en français.
Pourquoi ce module a-t-il été conçu ainsi, et qu'a-t-on essayé avant ?
Voix du lead developer
En juillet 2019, PostgreSQL subissait des verrous d'écriture aux pics de charge. La réplication en lecture seule a été tentée puis écartée (désynchronisation inacceptable pour le module comptable). Choix final : file Redis asynchrone pour isoler l'ingestion, moins risqué qu'une migration NoSQL vu les compétences de l'époque.
Sources
Interface illustrative
Ce qu'on peut lui demander
Ce sont les questions qu'un nouvel arrivant pose pendant ses trois premiers mois, et auxquelles il obtient aujourd'hui une réponse en interrompant quelqu'un.
Le code produit par un salarié dans ses fonctions vous appartient ; celui d'un prestataire dépend du contrat. Le recueil documente les décisions et les contraintes, ce qu'aucune licence ne couvre, et se tient à l'écart de tout secret d'infrastructure.
Recueilli et consultable
Exclu, sans exception
Le cadre juridique
Le code produit par un salarié dans ses fonctions appartient à l'employeur, celui d'un prestataire dépend du contrat. Le recueil documente les décisions et les contraintes, ce qui n'est couvert par aucune licence tierce, et se tient à l'écart du code sous licence restrictive. Les secrets d'infrastructure, clés et identifiants sont exclus du périmètre par principe.
Si une cession ou une due diligence est en cours, ouvrez la situation qui correspond. Sinon, la démonstration produit répondra plus vite qu'un rendez-vous.
Métier voisinCybersécuritéMême concentration, avec en plus une cartographie des risques qui vit dans une seule tête.
Métier voisinIA & DataLes équipes data affrontent la même perte, aggravée par une obligation de documentation qui arrive.