Votre système fonctionne très bien. Jusqu’au moment où la personne qui sait pourquoi travaille encore là.
Imaginez une entreprise qui dispose d’un système en fonctionnement depuis sept ans. Il a été construit par étapes. D’abord, il a été réalisé par une agence de développement. Ensuite, une partie a été reprise par un freelance. Plus tard, une autre équipe a ajouté un module B2B. L’agence suivante a connecté le CRM. Quelqu’un d’autre a encore intégré les paiements.
Le système fonctionne.
L’entreprise gagne de l’argent grâce à lui.
Les employés l’utilisent chaque jour.
Les clients ignorent même combien de processus se déroulent en arrière-plan.
Seulement, il y a un problème.
Plus personne ne sait exactement comment tout cela fonctionne.
Une partie de la documentation se trouve dans Confluence. Autre chose est resté sur Google Drive. Quelques informations sont dans des tickets. Une intégration a été décrite dans un e-mail d’il y a quatre ans.
Et la chose la plus importante, "c’est peut-être Łukasz qui s’en souvenait".
Sauf que Łukasz est parti il y a trois ans.
Et pendant trois ans, rien ne s’est passé.
Jusqu’à un certain mardi matin.
Le système fonctionne. Donc tout va bien ?
C’est l’un des états les plus trompeurs dans lesquels un système d’entreprise peut se trouver.
Il fonctionne.
Il n’y a pas de panne.
Les utilisateurs sont satisfaits.
L’équipe commerciale utilise l’application.
Les commandes passent.
Les données arrivent dans le CRM.
Les rapports se génèrent.
La réaction naturelle est donc : Ne touchons à rien. Pourquoi fouiller dans quelque chose qui fonctionne ?
Et en effet, il n’y a aucune raison de modifier un système qui fonctionne simplement parce qu’on le peut.
Le problème, c’est qu’un système peut être stable techniquement tout en étant très instable sur le plan organisationnel.
Il peut fonctionner aujourd’hui, mais personne ne sait ce qui se passera lorsqu’il faudra changer de serveur, de fournisseur d’API, de domaine, de bibliothèque, de méthode d’authentification ou un fragment du processus métier.
Il peut être opérationnel, mais dépendant d’une seule personne.
Il peut être sûr, mais personne ne sait où se trouvent toutes les clés d’accès.
Il peut évoluer, mais uniquement grâce à une personne qui connaît l’historique de toutes les décisions.
Et c’est précisément là qu’apparaît la notion de bus factor.
Combien de personnes peuvent disparaître avant que le projet ne commence à avoir des problèmes ?
Le bus factor est un concept très simple, bien que brutal.
On se demande : Combien de personnes doivent ne plus être disponibles pour que le projet cesse de pouvoir être maintenu efficacement ?
Si la réponse est : "Une", nous avons un problème.
Si la réponse est : "Deux, mais elles travaillent toutes les deux dans une autre entreprise", nous avons un problème encore plus grand.
Il ne s’agit évidemment pas d’une "disparition" littérale des personnes.
Un développeur peut quitter l’entreprise.
Un freelance peut mettre fin à sa collaboration.
Une agence peut cesser de gérer un client.
Un administrateur peut changer de poste.
La personne responsable d’une intégration précise peut partir dans un autre département.
Le détenteur du savoir peut simplement tomber malade ou être indisponible pendant plusieurs semaines.
Si, avec lui, disparaît la capacité à comprendre le système, l’entreprise n’a pas un problème de personnel.
Elle a un problème business.
Le code n’explique pas toujours pourquoi quelque chose fonctionne
On peut dire : "Après tout, nous avons le code source. Au besoin, un nouveau développeur le lira."
Théoriquement, oui.
En pratique, le code répond surtout à la question : comment le système fait quelque chose.
Il ne répond pas toujours à la question : pourquoi il le fait précisément de cette manière.
Et c’est une énorme différence.
Dans le code, il peut y avoir une condition : "Si le client a un certain type de compte, exécute l’opération X."
Un nouveau développeur peut la trouver.
Mais comment saura-t-il pourquoi ?
Il peut s’agir d’une exigence métier.
Il peut s’agir d’un reliquat d’une ancienne intégration.
Il peut s’agir d’une protection contre une erreur de l’API externe.
Il peut s’agir d’un contournement d’un problème survenu il y a cinq ans.
Il peut s’agir de la solution à un cas particulier d’un des plus gros clients.
Il peut y avoir une très bonne raison.
Ou aucune.
Sans contexte, c’est difficile à évaluer.
C’est pourquoi la documentation du système ne devrait pas se limiter à des instructions :
"cliquez ici, puis ici".
La documentation la plus précieuse décrit souvent les décisions et les dépendances, et pas seulement l’utilisation des fonctionnalités.
Le savoir le plus dangereux est celui qui n’existe que dans la tête de quelqu’un
Les entreprises ont très souvent de la documentation. Seulement, la documentation n’est pas toujours la même chose que le savoir.
Nous pouvons avoir une description de l’API, mais pas l’information expliquant pourquoi nous utilisons précisément cette API.
Nous pouvons avoir une procédure de déploiement, mais pas la liste de tous les endroits où il faut modifier la configuration.
Nous pouvons avoir une description de l’intégration, mais ne pas savoir ce qui se passera lorsque le fournisseur externe changera son mode d’autorisation.
Nous pouvons avoir une liste de serveurs, mais ne pas savoir lequel est critique pour un processus donné.
Nous pouvons avoir accès au dépôt, mais pas au compte où se trouve l’infrastructure de production.
Ce sont précisément ces éléments qui peuvent transformer un changement apparemment simple en une enquête de plusieurs jours.
L’intégration qui fonctionne depuis cinq ans reste une dépendance
L’un des domaines les plus souvent ignorés est celui des services externes ;
- Paiements.
- SMS.
- E-mail.
- CRM.
- ERP.
- Cartes.
- Systèmes de livraison.
- Plateformes marketing.
- Systèmes comptables.
- Services cloud.
- API externes.
- Bibliothèques open source.
Chacun de ces éléments fait partie d’un écosystème plus vaste.
Si un système utilise dix services externes, nous n’avons pas un seul système. Nous avons un système plus dix dépendances. Et chacune d’elles peut changer.
Le fournisseur peut modifier l’API.
Il peut mettre fin au service.
Il peut changer le modèle de tarification.
Il peut retirer l’ancienne version.
Il peut introduire de nouvelles exigences de sécurité.
Il peut être racheté par une autre entreprise.
C’est pourquoi la connaissance de l’origine des composants et des dépendances logicielles joue également un rôle de plus en plus important. Le NIST souligne notamment l’importance du SBOM, c’est-à-dire le Software Bill of Materials - un inventaire formel des composants utilisés pour construire un logiciel. Une telle liste aide à comprendre de quoi se compose le système et à évaluer plus rapidement l’impact des vulnérabilités ou des changements dans la chaîne d’approvisionnement.
Pour l’entreprise, on peut résumer cela à une question très simple :
Savez-vous de quoi dépend votre système ?
Et maintenant, imaginez un changement d’agence de développement
C’est l’un de ces moments où toutes les lacunes apparaissent au grand jour.
L’entreprise a travaillé pendant des années avec un seul prestataire. Soudain, la collaboration prend fin. Les raisons peuvent être nombreuses; changement de stratégie. changement de budget. rachat de l’agence. problèmes organisationnels. manque de compétences pour continuer le développement. Ou simplement l’entreprise veut travailler avec un autre partenaire.
La nouvelle société de développement demande :
"Où est le dépôt ?" - Il y est.
"Où est l’infrastructure ?" - Elle y est.
"Comment déployons-nous en production ?" - "Nous ne savons pas, c’était l’ancienne équipe qui s’en occupait."
"Comment fonctionne l’intégration avec l’ERP ?" - "Je crois que c’est via ce serveur."
"Quelles sont nos clés API ?" - "Elles devraient être dans l’e-mail."
"Quelles API sont en production ?" - "Nous ne savons pas."
"Quels processus sont critiques ?" - "Il faut demander à Łukasz."
Łukasz ne travaille déjà plus là-bas...
Et c’est précisément pourquoi la reprise d’un projet n’est pas seulement une reprise du code. Il faut aussi transférer les connaissances.
La documentation n’est pas un coût. C’est une assurance
Dans de nombreuses entreprises, la documentation est traitée comme quelque chose qu’on fait "quand on aura le temps".
Donc en général jamais.
Ou à la fin du projet.
Ou quand quelqu’un pose la question.
C’est une erreur.
La documentation est l’un des mécanismes qui réduisent le risque opérationnel. Elle ne génère pas directement de ventes. Elle n’améliore pas le taux de conversion. Elle n’a pas l’air spectaculaire dans une présentation.
Mais en situation de crise, elle peut faire la différence entre : "on répare ça aujourd’hui"
et : "il faut d’abord trouver la personne qui se souvient comment ça fonctionnait".
Dans les nouvelles directives du NIST concernant les plans de sécurité, de confidentialité et de gestion des risques liés à la chaîne d’approvisionnement logicielle, la documentation de l’objectif du système, de son état, des contrôles ainsi que des responsabilités et du comportement des personnes qui le gèrent est considérée comme un élément d’une gestion ordonnée du système.
Cela montre très bien l’évolution de la manière de penser.
La documentation n’est pas uniquement un outil pour le développeur.
C’est un élément de la continuité d’activité de l’organisation.
Que faut-il documenter ?
Il ne s’agit pas de créer une documentation de 800 pages que personne n’ouvrira jamais.
Une bonne documentation doit répondre avant tout aux questions qui apparaîtront lorsqu’un changement surviendra ou qu’un élément cessera de fonctionner.
- Qui est le propriétaire du système ?
- Où se trouve le code ?
- Où se trouve la production ?
- À quoi ressemble le processus de déploiement ?
- Quels sont les environnements ?
- Quelles sont les intégrations critiques ?
- Quels services externes utilisons-nous ?
- Qui en est le fournisseur ?
- Quels contrats et comptes avons-nous ?
- Où se trouvent les clés et les données d’accès ?
- Qui a les autorisations ?
- À quoi ressemble la sauvegarde ?
- À quoi ressemble la restauration du système ?
- Quels composants open source sont utilisés ?
- Quelles bibliothèques sont obsolètes ?
- Quelles sont les décisions architecturales les plus importantes ?
- Quels éléments sont critiques pour l’entreprise ?
- Que se passera-t-il si un service externe particulier cesse de fonctionner ?
Ce n’est pas une documentation "pour les programmeurs".
C’est une carte des dépendances de l’entreprise envers la technologie.
"Ça marche, alors ne touchons à rien" peut être une stratégie. Mais il faut en connaître le prix
Toutes les entreprises n’ont pas besoin de reconstruire leur ancien système.
Tous les systèmes legacy ne sont pas mauvais.
Il ne faut pas réécrire tout ancien code.
Bien au contraire - parfois, un système ancien et stable est une bien meilleure solution qu’une migration coûteuse effectuée sans raison précise.
Le problème n’est pas l’âge du système.
Le problème est le manque de connaissance de son état.
Si nous savons comment le système fonctionne, quelles sont ses dépendances, où se trouvent les risques et qui sait le maintenir, nous pouvons décider en connaissance de cause :
- nous le conservons,
- nous le modernisons,
- nous réécrivons une partie,
- nous le migrons,
- ou nous ne touchons à rien.
Si nous ne le savons pas, la décision "ne rien toucher" n’est pas une stratégie.
C’est un pari.
À quoi ressemble un audit d’un système hérité ?
Lorsqu’un système existant arrive dans une société de développement, la première étape ne devrait pas être : "Réécrivons-le." - Il faut d’abord le comprendre.
Un bon audit devrait couvrir notamment l’architecture de l’application, le code source, la base de données, l’infrastructure, le processus de déploiement, les dépendances, les intégrations, la sécurité, l’accès aux services et la documentation.
Mais il est tout aussi important de comprendre le business ;
- Quels processus sont critiques ?
- Quelles fonctions sont utilisées chaque jour ?
- Quels modules génèrent du chiffre d’affaires ?
- Quels éléments peuvent être désactivés sans conséquence ?
- Que se passe-t-il lorsqu’une intégration particulière cesse de fonctionner ?
- Quels éléments sont les plus risqués ?
Ce n’est qu’en combinant la perspective technique et la perspective business que l’on peut dire, ce qui nécessite vraiment un changement.
L’audit ne doit pas nécessairement se terminer par une révolution
Parfois, le résultat de l’audit est étonnamment simple.
Le système est en bon état, il faut seulement :
- Compléter la documentation.
- Mettre de l’ordre dans les accès.
- Mettre à jour quelques bibliothèques.
- Transférer la propriété des comptes.
- Décrire le processus de déploiement.
- Ajouter de la surveillance.
- Mettre en place une sauvegarde.
- Introduire une deuxième personne dans les domaines que seul un développeur connaissait.
Et soudain, le bus factor passe de 1 à 3.
Il n’est pas nécessaire de réécrire toute l’application.
Il n’est pas nécessaire de jeter sept ans de travail.
Il n’est pas nécessaire de tout reconstruire à zéro.
Parfois, le plus grand problème n’est pas la technologie.
C’est l’absence de carte.
Le système devrait survivre aux personnes qui l’ont créé
C’est sans doute la règle la plus importante : un bon système devrait être capable de survivre au départ du développeur.
Il devrait survivre au changement d’administrateur.
Il devrait survivre au changement de société de développement.
Il devrait survivre à la réorganisation de l’entreprise.
Il devrait survivre à plusieurs années de développement.
Cela ne signifie pas que chaque programmeur doit comprendre chaque ligne de code. Cela signifie que les connaissances critiques pour le fonctionnement de l’entreprise ne peuvent pas exister uniquement dans la tête d’une seule personne.
Car un employé peut partir.
Un freelance peut mettre fin à la collaboration.
Une agence peut disparaître.
Un fournisseur peut changer de service.
Et l’entreprise doit quand même continuer à fonctionner.
La technologie devrait appartenir à l’organisation, et non à la mémoire d’une seule personne
C’est particulièrement important dans le cas de systèmes construits pendant de nombreuses années.
Si l’entreprise paie pour un logiciel, elle devrait savoir non seulement où se trouve le code.
Elle devrait savoir :
- ce qu’elle possède,
- de quoi cela dépend,
- qui y a accès,
- qui peut le modifier,
- comment on peut le déployer,
- comment on peut le restaurer,
- comment on peut le transmettre à une autre équipe.
Le NIST, dans ses matériaux actuels sur le due diligence des fournisseurs, attire notamment l’attention sur l’origine, la résilience, les pratiques de cybersécurité et les dépendances dans la chaîne d’approvisionnement. Cela montre une orientation plus large : les organisations devraient de plus en plus savoir non seulement qui a fourni le système, mais aussi de quoi il est composé et quels risques sont liés à sa maintenance.
Ce n’est plus seulement un sujet pour le service informatique.
C’est un sujet de gestion du risque d’entreprise.
Le pire moment pour apprendre à connaître son système, c’est une panne
On peut consacrer quelques jours à un audit.
On peut mettre la documentation en ordre.
On peut vérifier les dépendances.
On peut décrire l’architecture.
On peut vérifier les accès.
On peut déterminer qui est vraiment responsable de chaque domaine.
On peut réduire le bus factor.
Ou bien on peut attendre.
Jusqu’au moment où le système cessera de fonctionner.
Alors, les questions seront exactement les mêmes.
Mais la pression sera plus forte, les utilisateurs attendront, les ventes pourront s’arrêter, et chaque heure coûtera de l’argent.
C’est pourquoi il vaut la peine de se poser une question avant que le problème n’apparaisse : Si demain la personne qui connaît le mieux votre système disparaissait, saurions-nous encore comment le maintenir ?
Si la réponse est « non », cela ne signifie pas encore que le système est mauvais.
Cela signifie que l’entreprise a un risque caché qu’elle n’a pas encore eu à activer.
Chez Web24, nous reprenons non seulement le code
La reprise d’un projet existant est un travail complètement différent du lancement d’un nouveau système à partir de zéro.
Il faut d’abord comprendre ce qui existe déjà.
Ce qui fonctionne.
Ce qui est critique.
Ce qui est une dépendance.
Ce qui est un problème.
Ce qui n’est que le vestige de décisions antérieures.
Et surtout — où se trouve la connaissance sans laquelle le système ne peut pas être développé en toute sécurité.
Ce n’est qu’alors qu’on peut planifier les actions suivantes.
Parfois, ce sera une modernisation.
Parfois, un développement.
Parfois, une mise en ordre de l’infrastructure.
Parfois, la reprise de la maintenance.
Et parfois, tout simplement, la création d’une vraie cartographie du système, que personne n’a eu le temps de préparer pendant des années.
Car un logiciel house responsable ne devrait pas construire une technologie qui ne fonctionne que lorsque la bonne personne est assise devant l’ordinateur.
Le système devrait être plus grand que la mémoire d’une seule personne.
Et l’entreprise devrait avoir la certitude que, lorsque quelqu’un s’en va, la technologie ne s’en va pas avec lui.
