Ton système fonctionne très bien. Jusqu’au jour où la personne qui sait pourquoi ne travaille plus là.
L’entreprise a un système qui a été développé pendant sept ans. Il fonctionne. Il sert les clients. Il se connecte à d’autres systèmes. Il exécute des processus sans lesquels l’entreprise ne pourrait pratiquement pas fonctionner normalement.
Au cours de ces sept années, cinq développeurs ont travaillé sur le projet. À cela s’ajoutent deux freelances et une agence. Une partie de la documentation se trouve dans Confluence, une partie sur Google Drive, une partie dans des tickets. Quelque part, il y a aussi un vieux document concernant l’une des intégrations. Et quand quelqu’un demande pourquoi un fragment précis du système fonctionne précisément de cette manière, la réponse est : "Je crois que Michał s’en souvenait."
Michał est parti il y a trois ans.
Et c’est précisément là que le vrai problème commence.
Pas parce que le système est mal écrit. Pas parce qu’il a soudain cessé de fonctionner. Le problème, c’est que l’entreprise a cessé de posséder une connaissance complète de son propre système.
Le système fonctionne, mais l’entreprise peut ne pas le contrôler
C’est l’une des formes les plus sous-estimées de la dette technologique.
Quand on parle de dette technologique, on pense généralement à du vieux code, à des bibliothèques obsolètes, à des erreurs d’architecture, à l’absence de tests ou à des solutions qui étaient autrefois rapides mais qui freinent aujourd’hui le développement.
Pendant ce temps, il existe un autre type de dette. La dette de connaissance.
Elle apparaît lorsqu’un système dépend d’informations qui ne figurent ni dans la documentation, ni dans le dépôt, ni dans les procédures, ni dans l’organisation, mais uniquement dans la tête de certaines personnes.
Et tant que ces personnes sont disponibles, tout peut sembler normal.
Le problème apparaît lors d’un changement d’équipe, du départ d’un développeur, de la fin d’une collaboration avec une agence de développement, d’une panne de serveur, d’un changement d’administrateur ou de la nécessité de déployer rapidement une nouvelle solution.
Soudain, il s’avère que l’entreprise a le code, mais pas la connaissance.
Elle a un serveur, mais pas la certitude de savoir qui y a accès.
Elle a une intégration, mais on ne sait pas sur quel compte elle a été créée.
Elle a une documentation, mais on ne sait pas quelle version est à jour.
Elle a un processus, mais on ne sait pas pourquoi il a été conçu ainsi.
Et alors une question surgit très vite : qui est réellement le propriétaire de ce système ?
Le bus factor, ou que se passe-t-il si une personne disparaît ?
Dans le monde de l’IT, on utilise la notion de bus factor. En simplifiant, elle désigne le nombre de personnes dont l’indisponibilité peut faire en sorte que l’équipe ne soit plus en mesure de développer ou de maintenir efficacement le projet.
Il ne s’agit évidemment pas d’un événement littéral. C’est une façon de penser la concentration des connaissances.
Si une seule personne sait comment fonctionne une intégration critique, le bus factor pour cette connaissance est de un.
Si un seul administrateur a accès à la production, le bus factor est de un.
Si un seul homme sait pourquoi le système exécute un processus donné chaque nuit, le bus factor peut être de un.
Si l’entreprise collabore avec une agence de développement externe et que, côté client, personne ne comprend l’architecture de la solution, un problème encore plus grand se pose - la connaissance peut se trouver en dehors de l’organisation.
Cela ne veut pas dire que chaque entreprise doit avoir cinq experts pour chaque fragment du système.
Il s’agit de quelque chose de beaucoup plus simple : l’entreprise devrait savoir où se trouve la connaissance critique et si elle peut la récupérer sans une personne précise.
Le code dit comment. Il ne dit pas toujours pourquoi.
Un développeur peut lire le code et comprendre ce que fait une fonction donnée.
Mais il ne saura pas toujours pourquoi elle a été écrite exactement de cette manière.
C’est une énorme différence.
On peut trouver le fragment responsable de l’envoi de données vers un système externe. On peut analyser l’endpoint, les paramètres, l’autorisation et la gestion des erreurs.
Mais le code ne répondra pas nécessairement aux questions :
- Pourquoi les données sont-elles envoyées à 2h00 du matin ?
- Pourquoi ce statut précis est-il ignoré ?
- Pourquoi, après une erreur, le système réessaie-t-il exactement trois fois ?
- Pourquoi une valeur est-elle recalculée avant l’envoi ?
- Pourquoi ne peut-on pas modifier l’ordre de ces opérations ?
- Pourquoi cette intégration utilise-t-elle un compte précis ?
La réponse peut se trouver dans l’historique du projet, dans un ancien ticket, dans un e-mail d’il y a six ans ou - pire encore - uniquement dans la mémoire de la personne qui ne travaille déjà plus dans l’entreprise.
C’est pourquoi une bonne documentation ne devrait pas être uniquement un mode d’emploi indiquant "quoi cliquer".
Elle devrait aussi conserver le contexte et les décisions.
Le plus gros problème peut être une intégration dont plus personne ne se souvient
Un système moderne ne fonctionne presque jamais totalement de manière autonome.
Il se connecte à un système ERP. À un CRM. À une passerelle de paiement. À un fournisseur de SMS. À un système de livraison. À l’API d’un partenaire. À un service cloud. À une plateforme analytique. À un système comptable. À un mécanisme d’autorisation.
Chaque connexion de ce type fait partie de la chaîne technologique.
Et chaque maillon de cette chaîne peut avoir son propre propriétaire, compte, clé API, certificat, contrat, limite, version d’API et cycle de vie.
Après quelques années, plus personne ne se souvient peut-être de qui a créé tel compte.
Et alors il suffit de l’expiration d’un certificat ou d’un changement d’API pour que le système cesse de fonctionner.
C’est encore pire si l’entreprise ne sait même pas qu’une dépendance donnée existe.
C’est pourquoi, dans une approche mature des systèmes, la provenance du logiciel, la gestion des dépendances et la transparence de la chaîne d’approvisionnement logicielle prennent de plus en plus d’importance. Le NIST, dans ses documents actuels concernant la sécurité de la chaîne d’approvisionnement, souligne notamment l’importance des informations sur les composants, leur origine, leur cycle de vie et leurs dépendances. Le SBOM, c’est-à-dire Software Bill of Materials, est l’un des outils permettant d’organiser la connaissance de ce qui compose un logiciel.
Ce n’est plus seulement un sujet pour l’équipe sécurité.
C’est aussi un sujet pour le comité de direction.
Car si l’entreprise ne sait pas de quoi son système est construit, il lui est plus difficile d’évaluer le risque, le coût de maintenance et les conséquences des changements.
La documentation n’est pas un coût. C’est une police d’assurance.
Dans de nombreuses entreprises, la documentation est traitée comme quelque chose que l’on "fera plus tard".
D’abord la fonctionnalité.
Ensuite le déploiement.
Puis les corrections.
Ensuite un autre projet.
Et la documentation ?
"Quand on aura le temps."
Le problème, c’est que le temps pour documenter arrive généralement quand il est déjà trop tard.
La documentation devrait fonctionner comme une assurance business. Pas parce que quelqu’un la lira tous les jours. Au contraire - pourvu qu’elle soit le moins souvent possible nécessaire en situation de crise.
Mais lorsqu’un problème survient, l’entreprise devrait pouvoir répondre à des questions fondamentales :
- Comment fonctionne le système ?
- De quoi se compose-t-il ?
- Où se trouve l’environnement de production ?
- Qui a accès ?
- Quelles sont les intégrations critiques ?
- Quels comptes et services externes sont utilisés ?
- Quelles sont les dépendances ?
- Comment les sauvegardes sont-elles effectuées ?
- À quoi ressemble le processus de déploiement ?
- Que se passe-t-il en cas de panne ?
- Quels éléments sont critiques pour l’entreprise ?
- Pourquoi les décisions architecturales clés ont-elles été prises ?
- Qui peut reprendre la maintenance du système ?
Cela ne veut pas forcément dire des centaines de pages de documentation.
Une bonne documentation doit avant tout être utile, à jour et accessible aux bonnes personnes.
« Ne touchons pas si ça fonctionne » n’est pas toujours une mauvaise décision
Il y a encore un autre problème très fréquent.
Le système fonctionne depuis des années, donc l’entreprise adopte le principe : « On ne touche pas. Ça marche. »
Et parfois, c’est tout à fait raisonnable.
Chaque vieille technologie ne doit pas être remplacée immédiatement. Chaque ancien fragment de code ne doit pas être réécrit. Chaque bibliothèque n’annonce pas une catastrophe. Chaque architecture d’il y a quelques années n’est pas erronée.
Le problème commence lorsque « ne touchons pas » signifie aussi :
- « N’analysons pas. »
- « Ne documentons pas. »
- « Ne vérifions pas les dépendances. »
- « Ne demandons pas qui a accès. »
- « Ne vérifions pas si nous avons encore tous les comptes. »
- « Ne déterminons pas ce qui se passera si l’exécutant actuel n’est plus disponible. »
Alors l’absence de changement n’est pas une stratégie.
C’est reporter le risque.
Parfois, la meilleure décision technique est réellement de ne rien reconstruire.
Mais cette décision devrait découler de la connaissance du système, et non du manque de connaissance du système.
Que devrait couvrir un audit d’un système hérité ?
Lorsqu’une entreprise reprend un système après un autre logiciel house, un freelance ou une équipe interne, la première étape ne devrait pas être de tout réécrire automatiquement.
Il faut d’abord comprendre ce qui a réellement été repris.
L’audit devrait répondre au moins à quelques domaines fondamentaux.
Architecture. Comment le système est-il construit ? Quels sont ses principaux composants ? Où se trouvent les données ? Comment les différents éléments communiquent-ils ?
Code et dépôts. L’entreprise possède-t-elle le code source complet ? Sait-on quelle branche et quelle version sont en production ? Le processus de build et de déploiement peut-il être reproduit ?
Infrastructure. Où tourne la production ? À quoi ressemble l’environnement de test ? Qui a accès ? À quoi ressemblent la surveillance et les sauvegardes ?
Intégrations. Avec quoi le système communique-t-il ? Quelles API utilise-t-il ? Qui est propriétaire des différents comptes et clés ?
Dépendances. Quelles bibliothèques, frameworks et composants externes sont utilisés ? Sont-ils mis à jour ? Ont-ils des problèmes de sécurité connus ? À quoi ressemble leur cycle de vie ?
Processus de déploiement. Une nouvelle personne est-elle capable de préparer, tester et déployer une modification sans téléphoner à l’ancien développeur ?
Connaissance. Qu’est-ce qui se trouve dans la documentation, et qu’est-ce qui n’existe encore que dans la tête des gens ?
Risque business. Que se passera-t-il si un composant donné cesse de fonctionner pendant une heure, un jour ou une semaine ?
L’approche contemporaine de la sécurité de la chaîne d’approvisionnement logicielle met de plus en plus l’accent sur la nécessité de connaître les composants, les fournisseurs, les dépendances, leur origine et leur cycle de vie. Le NIST souligne également l’importance de la due diligence envers les fournisseurs technologiques et de l’évaluation de la résilience et du risque liés à l’ensemble de la chaîne d’approvisionnement.
L’audit ne signifie pas « réécrivons le système à partir de zéro »
C’est important, car l’audit technique est souvent à tort assimilé à une reconstruction.
Pourtant, l’audit peut se terminer par une conclusion très simple : « Le système est correct. Il faut seulement remettre la connaissance en ordre et supprimer quelques risques. »
Il peut aussi s’avérer que le système ne nécessite une modernisation que dans un seul domaine.
Ou que le plus grand problème n’est pas le code, mais l’absence d’accès à l’infrastructure.
Ou que l’application est bien écrite, mais que personne n’a de connaissance à jour du processus de déploiement.
Ou que tout fonctionne, mais que l’entreprise dépend d’un seul fournisseur externe.
C’est pourquoi une bonne analyse d’un projet hérité devrait répondre à la question : « Qu’est-ce qu’il faut vraiment changer, et qu’est-ce qu’il ne faut pas toucher ? »
Ce n’est qu’alors qu’on peut prendre des décisions d’investissement.
Et si vous changiez de logiciel house ?
C’est l’un des moments où le problème de la dette de connaissance invisible apparaît au grand jour.
L’entreprise met fin à la collaboration avec le prestataire.
Le nouveau partenaire reçoit le dépôt.
Et commence à poser des questions :
- « Où est la production ? »
- « Comment lancer le projet en local ? »
- « Quelle version est actuelle ? »
- « À quoi sert ce service ? »
- « Qui possède le compte pour cette API ? »
- « Que fait ce cron ? »
- « Pourquoi ce processus se lance-t-il à cette heure-ci ? »
- « D’où vient ce paramètre ? »
- « Que se passera-t-il si nous le désactivons ? »
Si la réponse à la plupart des questions est « nous ne savons pas », le nouveau logiciel house ne reprend pas le projet. Il doit d’abord le redécouvrir.
Et la découverte du système prend du temps. Du temps que le client paiera plus tard.
C’est pourquoi la transmission d’un projet entre équipes devrait être un processus, et non un envoi d’un ZIP de code et du mot de passe d’un seul compte.
Le système doit survivre aux gens
C’est probablement la règle la plus importante.
Les gens changent. Les développeurs changent de travail. Les freelances terminent leur collaboration. Les logiciels houses changent de clients. Les administrateurs partent dans d’autres entreprises. Les directions changent.
Le système reste.
C’est pourquoi le système devrait être conçu de manière à ce que les connaissances nécessaires à sa maintenance puissent être récupérées.
Cela ne signifie pas que chaque employé doit tout savoir.
Cela signifie que l’organisation devrait disposer d’un mécanisme de stockage des connaissances :
- Dépôts.
- Documentation.
- Registre des intégrations.
- Informations sur l’infrastructure.
- Accès gérés par l’entreprise.
- Description des processus clés.
- Historique des décisions importantes.
- Informations sur les dépendances.
- Procédures d’urgence.
- Et surtout - des personnes capables d’utiliser cette documentation.
Le NIST, dans ses directives actuelles sur la planification de la sécurité des systèmes, attire également l’attention sur la définition formelle des responsabilités, du statut opérationnel du système ainsi que des rôles des personnes qui le gèrent, le soutiennent ou y ont accès.
Cela montre un changement plus large dans la manière de penser la technologie.
Un système n’est pas seulement du code. Un système, ce sont aussi des personnes, des processus, de l’infrastructure, des dépendances, des données, des accès et des responsabilités.
Chez Web24, nous commençons souvent justement par la question : « Qu’est-ce qu’on a ici, au juste ? »
La reprise d’un projet existant ne devrait pas commencer par la promesse que tout sera réécrit à partir de zéro.
Cela devrait commencer par comprendre la situation :
- Qu’est-ce qui fonctionne ?
- Qu’est-ce qui ne fonctionne pas ?
- Qu’est-ce qui est critique ?
- Qu’est-ce qui est obsolète ?
- Où se trouvent les plus grands risques ?
- Qu’est-ce qui manque dans la documentation ?
- Quelles dépendances sont invisibles ?
- Peut-on faire évoluer le système existant en toute sécurité ?
- Faut-il une modernisation ou seulement une remise en ordre ?
Ce n’est qu’ensuite qu’on peut décider s’il faut faire évoluer le projet, le reconstruire, en réécrire une partie ou simplement le documenter correctement.
C’est particulièrement important pour les projets qui ont été développés pendant des années par différentes personnes et différentes entreprises.
Car un bon partenaire technologique ne devrait pas être nécessaire seulement parce que lui seul sait comment fonctionne le système.
Il devrait être nécessaire parce qu’il sait faire évoluer ce système, le sécuriser et transmettre le savoir plus loin.
L’erreur la plus dangereuse peut être la personne qui est déjà partie
Le problème n’est pas toujours le vieux code.
Le problème n’est pas toujours la technologie obsolète.
Le problème n’est pas toujours l’absence du dernier framework.
Parfois, le plus grand risque est une information que personne n’a consignée.
Un seul mot d’ordre.
Une seule décision architecturale.
Une seule intégration.
Une seule exception dans le processus.
Une seule personne qui, pendant des années, savait comment cela fonctionnait.
Puis elle est partie.
C’est pourquoi il vaut la peine de se poser aujourd’hui une question très simple : Si demain la personne qui connaît le mieux votre système disparaissait de l’entreprise, seriez-vous encore capables de le gérer ?
Si la réponse est « oui » - parfait.
Si elle est « je ne sais pas » - il vaut la peine de vérifier.
Et si elle est « définitivement non » - vous avez probablement justement trouvé l’un des domaines les plus importants de risque technologique dans votre entreprise.
Le système devrait être plus grand que la mémoire d’une seule personne.
