Dépendance à un seul développeur : le risque invisible

Le risque que la direction n'a pas vu : un seul développeur porte le logiciel

L'entreprise vend en ligne, dans le retail, et elle grandit. L'équipe technique compte 5 développeurs, 1 responsable produit et un designer à mi-temps. La mission commandée n'avait rien à voir avec un risque : il s'agissait d'amener l'IA dans l'équipe pour livrer plus vite. Première demande, le premier jour : la documentation. La réponse est venue du développeur principal lui-même : « il n'y en a pas encore, tout est dans les têtes ».

Ce « pas encore » est déjà un indice. Il dit que tout le monde sait qu'il en faudrait, et que personne n'en a jamais eu besoin, parce que la réponse à toute question se trouvait à 2 bureaux de là. Le déclic est venu d'un détail d'accès : lui seul pouvait entrer dans l'hébergement chez Amazon et y voir l'architecture. Quelques jours d'interviews et de lecture du code plus tard, le constat tenait en une liste. Une seule personne, le développeur principal côté serveur, portait les 5 choses suivantes :

L'hébergement chez Amazon, découpé en microservices : 7 petits programmes indépendants qui se parlent entre eux, et dont lui seul avait les accès.
Tout le code côté serveur, celui que vos utilisateurs ne voient jamais et qui fait tourner le service.
Toute la logique métier : les règles de gestion, qui a droit à quoi, ce qui se passe quand un cas sort de l'ordinaire.
La mise en place de l'IA dans l'équipe, qu'il avait initiée seul.
La facturation des abonnements, dont on reparle plus bas.

Les autres développeurs travaillaient sur les interfaces, ou sur une autre partie du serveur. Aucun n'avait touché à l'hébergement ni à la facturation. Si cette personne partait un vendredi, le lundi l'entreprise ne savait plus livrer une version sans prendre un risque sur sa production, et personne ne pouvait dire lequel.

Présenté à la direction, le constat n'a surpris personne. La réponse a été immédiate : on priorise la documentation. Le risque n'était pas ignoré, il était minimisé, parce que la direction voyait des versions livrées, des clients facturés et une équipe qui s'entendait bien. Le risque n'apparaît dans aucun de ces 3 indicateurs.

Les assureurs ont un nom pour ça, le risque de l'homme clé : la personne dont l'absence arrête l'activité. Les développeurs le mesurent d'une autre façon, en comptant combien de personnes doivent manquer en même temps pour que le projet s'arrête. Ici, la réponse était 1. Ce chiffre ne se lit dans aucun tableau de bord, et c'est précisément pour ça qu'il faut aller le chercher.

5 signaux que votre logiciel dépend d'une seule personne

Vous n'avez pas besoin d'ouvrir le code pour repérer ce risque. Les 5 signaux ci-dessous se voient depuis un bureau de direction, à condition de les chercher :

Toute question sur le fonctionnement finit chez la même personne: Vous demandez comment marche la facturation, comment on livre une version, pourquoi telle règle existe. Quelle que soit la personne à qui vous posez la question, la réponse est « il faut demander à lui ». Un logiciel dont l'explication passe toujours par la même tête est un logiciel que personne d'autre ne comprend.
Quand cette personne est absente, certaines choses ne se font pas: Le plus fréquent : on ne met pas en production, c'est-à-dire qu'on ne livre pas la nouvelle version aux clients. Une version est prête, testée, validée, et elle attend son retour parce que lui seul sait livrer sans risque. Regardez le calendrier des mises en production et celui de ses congés : s'ils se superposent, vous avez votre réponse.
C'est lui qui touche aux éléments les plus critiques: La facturation, l'architecture, les accès. Personne d'autre n'y va, d'abord parce que c'est dangereux, ensuite parce qu'il est plus rapide. Avec le temps, la zone qu'il est seul à toucher grandit, et la zone que les autres connaissent rétrécit.
C'est un mouton à 5 pattes qui a l'ancienneté: Il sait tout faire, il connaît le métier par cœur, il était là avant les autres. La direction le décrit comme son meilleur élément, et elle a raison. Le problème n'est pas sa qualité, c'est qu'elle n'a jamais été transmise, parce que personne n'en a eu besoin tant qu'il était là.
On l'appelle pendant ses congés quand il y a un problème: Tout le monde trouve ça normal, lui compris. Chaque appel en vacances est une preuve que le logiciel ne tourne pas sans lui. Comptez ces appels sur les 12 derniers mois : c'est la mesure la plus honnête de votre dépendance.

Les 5 signaux passent le plus souvent pour des qualités. C'est bien le problème : chacun de ces signaux décrit un excellent développeur. Aucun ne décrit une entreprise en sécurité.

La facturation, le savoir le plus critique et le moins partagé

On croit souvent que le code critique, c'est celui que les clients voient : le site, l'application, le parcours d'achat. Dans l'entreprise racontée ici, le code critique était invisible : la facturation des abonnements. Un paiement récurrent, passé par le prestataire Stripe, mais avec un système d'abonnement maison : 48 grilles d'abonnement actives, chacune avec ses options, ses périodes et ses tarifs.

Le système d'abonnement avait été écrit par une seule personne. La question posée à la direction tenait en 4 mots : qui d'autre comprend ça ? Qui sait comment ça marche, qui a conscience des risques, qui mesure ce qu'une erreur peut faire sur le chiffre d'affaires et chez les clients ? La réponse honnête : pas grand monde.

Cherchez chez vous dans le même ordre. Le savoir le plus critique se trouve aux 3 endroits où une erreur se transforme en argent perdu ou en client perdu en quelques jours :

La facturation : ce qui encaisse, ce qui rembourse, ce qui relance.
La mise en production : la façon dont une modification arrive jusqu'à vos utilisateurs, et ce qui se passe quand elle casse.
Les données : où elles sont, qui y accède, et comment on les restaure.

Sur ces 3 sujets, une seule personne qui sait est un risque à traiter en priorité. Le reste du logiciel peut attendre.

Pourquoi un développeur bien payé part quand même

On se dit volontiers qu'un développeur bien payé, là depuis des années, ne partira pas. Les gens ne restent pas à vie dans une entreprise, et les meilleurs encore moins. Les raisons d'un départ sont toujours les mêmes, et une augmentation n'en règle durablement aucune :

Une ambition que l'entreprise ne peut pas satisfaire : un titre, un périmètre, une équipe à diriger.
Un désaccord avec la direction sur une décision qui le concerne.
La fatigue d'être appelé le dimanche depuis des années.
Une offre ailleurs, ou un accident de la vie, qui n'attendent pas votre plan de succession.

Le point qui compte pour vous : la décision de partir se prend du jour au lendemain, et le préavis ne la rattrape pas. Un préavis de 3 mois, quand il est fait, ne transfère aucun savoir. Un développeur qui part n'a plus de raison d'écrire ce qu'il a dans la tête, et personne n'est prêt à le recevoir. Si le risque n'a pas été identifié avant, ces 3 mois servent à constater les dégâts.

Le bon salaire n'est pas une protection : c'est un symptôme de la dépendance. Il est bien payé parce que l'entreprise sent qu'elle ne peut pas se passer de lui. Le jour où il compare ce salaire à la responsabilité qu'il porte seul, l'écart lui donne une raison de plus.

Documenter le savoir avec l'IA sans braquer votre développeur

Vous ne pouvez pas dire à votre meilleur élément : « on documente tout parce qu'on a peur que tu partes ». Il l'entendrait comme une défiance, et vous fabriqueriez le départ que vous vouliez éviter. Dans l'entreprise racontée ici, la porte d'entrée a été la mission elle-même : amener l'IA dans l'équipe pour livrer plus vite.

La vélocité est un vrai motif, et c'est ce qui rend la démarche efficace. Un assistant de programmation ne livre vite que s'il connaît l'architecture, les règles métier et les conventions de l'équipe. Sans documentation, il invente. La documentation est donc le carburant de la vitesse promise, et personne n'a de raison de s'y opposer, surtout pas celui qui a lui-même introduit l'IA dans l'équipe. La passe a suivi 3 étapes :

Des interviews du développeur, sujet par sujet : l'hébergement, la mise en production, la facturation, les règles métier. Il explique, on prend des notes, on pose les questions qu'un nouvel arrivant poserait.
L'assistant lit le code et rédige : la carte de l'architecture, la procédure de mise en production, le fonctionnement de la facturation. Le développeur relit et corrige, ce qui lui prend une heure là où écrire lui aurait pris une semaine.
La documentation vit au même endroit que le code, et elle sert immédiatement : c'est elle que l'assistant lit avant chaque tâche. Une doc qui sert tous les jours reste à jour ; une doc rangée dans un wiki que personne n'ouvre se périme sans que personne le voie.

La démarche donne 2 résultats pour le prix d'un. L'équipe livre plus vite, ce qui était la commande. Et une partie du savoir qui tenait dans une tête est maintenant écrite, lisible par un humain et par une machine. Le développeur, lui, a été traité comme la source de vérité qu'il est, pas comme un risque. Il a bien réagi : les interviews portaient sur l'IA, il était d'accord pour documenter, et il n'a rien retenu, parce qu'il avait lui-même conscience du risque.

Ne considérez une documentation comme finie que lorsqu'un autre développeur a mis en production en la suivant, sans appeler personne. Tant que ce test n'est pas passé, vous avez un document, pas un transfert de savoir. Sur cette mission, ce test n'a pas eu lieu : un mois n'a pas suffi pour aller jusque-là. C'est la première chose que la personne qui reprendra la direction technique devra faire.

Simplifier l'architecture pour réduire la dépendance

La dépendance ne tient pas seulement à une personne. Elle tient aussi à la complexité que cette personne a construite, et les 2 vont ensemble. Cette entreprise faisait tourner et surveiller 7 programmes indépendants, son découpage en microservices, pour une facture d'hébergement d'environ 3 000 € par mois. Ce découpage était surdimensionné pour son besoin. Un seul programme bien organisé aurait couvert le même service, avec moins de pièces à comprendre pour quelqu'un qui arrive.

Le constat a été dit à la direction, et elle en est consciente. La décision de simplifier reviendra à la personne qui portera la direction technique dans la durée. Une refonte d'architecture engage l'équipe pour des années, et elle ne se décide pas depuis une mission d'un mois. Le rôle du regard extérieur était de poser le sujet sur la table avec ses conséquences, pas de trancher à la place de celui qui vivra avec.

Une architecture plus grosse que le besoin est une dépendance de plus. Chaque pièce supplémentaire est une pièce que le nouveau venu doit comprendre avant de toucher à quoi que ce soit, et une pièce de plus que seul l'ancien connaît. La même question vaut pour la taille de l'équipe : avec l'IA, une équipe de 5 livre plus qu'elle ne livrait il y a 2 ans. Le sujet est moins d'ajouter des bras que de partager ce que les bras existants savent.

Reprise d'un logiciel existant quand il n'y a plus personne

Suivez l'ordre ci-dessous si la personne est déjà partie, que le logiciel tourne encore et que personne ne sait comment. Rien n'est perdu tant que le service fonctionne, à condition de respecter cet ordre :

Reprendre les accès avant tout le reste: L'hébergement, le dépôt de code, les mots de passe et clés d'accès, les comptes chez les fournisseurs, dont celui qui encaisse vos paiements. Tant que ces accès sont dans une boîte mail personnelle ou un téléphone qui n'est plus dans l'entreprise, rien d'autre ne peut commencer.
Faire lire le code par l'IA, avant de le faire lire par un humain: Un assistant de programmation explore un projet entier en quelques heures et en tire une carte : les programmes, les flux entre eux, les points d'entrée, les endroits où la règle métier est écrite. Cette carte ne remplace pas la personne partie, mais elle donne à celui qui reprend un point de départ que personne n'avait.
Ne pas réécrire: La tentation est forte quand personne ne comprend l'existant. Réécrire un logiciel dont on n'a pas la doc revient à redécouvrir chaque règle métier par les plaintes de vos clients. Faites d'abord tourner, puis documenter, puis décider.
Faire auditer avant de recruter: Recruter quelqu'un pour reprendre un logiciel inconnu revient à lui demander de faire l'audit en même temps que le travail. Un audit court donne la liste des risques et l'ordre pour les traiter, et vous permet de recruter ou de sous-traiter sur une fiche de poste réelle.

L'IA a changé une chose dans cette situation : un logiciel sans documentation n'est plus un logiciel illisible. Un assistant de programmation en tire une carte en quelques heures, là où un développeur seul mettait des semaines à se repérer. La carte prend des heures ; comprendre ce qu'elle décrit prend des semaines. L'IA n'a pas changé le reste : le pourquoi des règles métier et la mémoire des incidents passés sont partis avec la personne. Ces 2 savoirs se reconstituent auprès de vos équipes métier et de vos clients, pas dans le code.

Si votre situation ressemble à ça, 2 décryptages détaillent la suite : la reprise de projet informatique pour les 48 premières heures et la propriété du code, et l'audit technique d'une application pour ce qu'on regarde et le livrable à demander.

Comment dérisquer la dépendance à un développeur : la séquence, dans l'ordre

Voici les 7 étapes à suivre, dans cet ordre, tant que la personne est encore là :

1
Avertir votre direction, par écrit, que le logiciel tient sur une seule personne. Sans ce papier, le risque reste une intuition, et on ne budgète pas une intuition.
2
Lister ce que cette personne est seule à savoir faire. Pas ses compétences : les actions concrètes. Mettre en production, corriger une facture, redémarrer un service, donner un accès.
3
Repérer, dans cette liste, les éléments critiques : ceux où un départ se transforme en perte de chiffre d'affaires en quelques jours. Ici, c'était la facturation et la mise en production. Chez vous, ce sera peut-être autre chose.
4
Documenter avec l'IA, à partir d'interviews de la personne concernée. L'assistant lit le code et rédige, elle corrige, la doc vit à côté du code.
5
Faire tester la documentation par quelqu'un d'autre : une mise en production réalisée par un autre développeur, en suivant la doc, sans appeler personne. Si ça ne passe pas, la doc n'est pas finie.
6
Décider ensuite de l'architecture. Simplifier ce qui est plus gros que le besoin, et confier cet arbitrage à la personne qui portera la direction technique dans la durée.
7
Recommencer tous les 6 mois. Le savoir se reconcentre naturellement sur celui qui va le plus vite ; la dépendance revient si personne ne la mesure.

Posez la première question, celle que personne ne pose tant que tout marche, et acceptez la réponse. Et si vous construisez vos outils vous-même, lisez d'abord ce que tranche une direction technique quand le dirigeant automatise seul. Dans ce cas, la seule personne qui sait, c'est vous.

Faire mesurer ma dépendance Parler de mon équipe

Questions fréquentes

Comment savoir si mon entreprise dépend trop de son développeur ?

Posez 3 questions à votre équipe, sans lui : qui peut mettre en production demain matin, qui peut corriger une facture erronée, qui peut expliquer pourquoi le logiciel est organisé comme ça. Si les 3 réponses désignent la même personne, votre entreprise dépend d'elle. Les 5 signaux de cet article donnent le détail.

Faut-il recruter un second développeur pour réduire le risque ?

Pas en premier. Un second développeur mis à côté du premier sans documentation apprend par imitation, et vous avez 2 personnes qui savent, dont 1 qui sait vraiment. Documentez d'abord, faites tester la doc par quelqu'un d'autre, puis décidez si le volume de travail justifie un recrutement. Avec l'IA, la même équipe livre davantage qu'avant : le besoin de bras a baissé, le besoin de savoir partagé non.

L'assurance homme clé couvre-t-elle ce risque ?

Elle vous rend de l'argent en cas de décès ou d'invalidité de la personne assurée. Elle ne vous rend ni la connaissance du logiciel, ni la capacité de livrer, et elle ne couvre pas la démission. Elle a sa place dans une gestion de risque, après la documentation, pas à la place.

Comment documenter un logiciel sans bloquer les livraisons ?

En faisant écrire la doc par l'IA à partir du code et d'interviews, et non par le développeur sur son temps de livraison. Une interview dure 1 heure, l'assistant rédige, le développeur relit. Sur la mission racontée ici, la passe complète a tenu en 1 mois, en parallèle des livraisons. Un décryptage montre la documentation qui sert de carburant à l'IA sur un projet réel.

Que faire si le développeur est déjà parti ?

Reprendre les accès, faire lire le code par l'IA pour en tirer une carte, ne rien réécrire, et faire auditer avant de recruter. Le décryptage sur la reprise de projet informatique détaille les 48 premières heures et la propriété du code, et celui sur l'audit technique décrit ce qu'on regarde et le livrable à demander.

L'IA peut-elle remplacer le développeur qui part ?

Non. Elle lit le code, elle explique ce qu'il fait, elle rédige la documentation et elle écrit une bonne partie du nouveau code. Elle ne sait pas pourquoi une règle métier existe, ce qui se passe chez vos clients quand la facturation se trompe, ni ce qu'il ne faut surtout pas toucher un vendredi soir. Ce savoir doit être extrait de la personne tant qu'elle est là.

Combien de temps prend une passe de dérisquage ?

Comptez 1 mois pour une équipe de 5 développeurs et un logiciel de taille moyenne : interviews, lecture du code par l'IA, documentation de l'architecture, du déploiement et de la facturation, puis un test de mise en production par quelqu'un d'autre. Le constat lui-même, savoir que le risque existe, prend quelques jours.

Sources

Références consultées pour cette version du 3 septembre 2026. Le cas raconté est réel et anonymisé : le secteur, la taille de l'équipe et les chiffres sont exacts, le reste ne permet pas d'identifier l'entreprise ni la personne.