Le risque homme-clé : avez-vous acheté un produit ou une personne

Le risque homme-clé d’une startup tient en une question : si cette personne démissionne le lendemain du closing, achetez-vous encore la même chose ? Dans les cibles de moins de trente personnes, la réponse honnête est souvent non. Le produit fonctionne, les clients paient, la démo est fluide, et pourtant l’essentiel de la valeur loge dans une ou deux têtes libres de partir.

Ce risque ne s’évalue pas à l’intuition. Il se cartographie : qui peut faire fonctionner, réparer et reconstruire chaque partie du système. C’est un exercice concret, qui tient dans le calendrier d’une due diligence, et dont les clauses de rétention du contrat devraient découler directement. Voici comment nous le menons.

Cartographier qui peut reconstruire le système

La méthode repose sur une question répétée brique par brique : qui a construit ce composant, qui l’a modifié dans les six derniers mois, qui l’a débogué en production un dimanche soir. Trois noms différents, et le système survivra à un départ. Le même nom partout, et vous n’évaluez plus un actif technologique : vous évaluez la loyauté d’un individu.

L’historique git donne une première lecture, factuelle et difficile à maquiller. Si 80 % des commits sur le cœur du produit viennent d’une seule personne sur les douze derniers mois, la concentration est établie, quel que soit le discours. L’historique des incidents donne la seconde : qui apparaît dans chaque résolution de panne. Les astreintes, quand elles existent, complètent le tableau.

Restent les entretiens. Le test le plus simple consiste à demander à un second ingénieur d’expliquer le pipeline de données ou la chaîne de déploiement. S’il raconte le système avec ses propres mots, le savoir circule. S’il renvoie vers son collègue au bout de deux minutes, vous tenez votre réponse.

Les systèmes IA concentrent le savoir plus fort encore

Le logiciel classique laisse des traces lisibles : une architecture se lit dans le code, un schéma de base de données se comprend, une API se documente. Les systèmes IA ajoutent une couche de décisions qui ne se lit nulle part. Pourquoi ce prompt est formulé ainsi. Pourquoi le seuil de similarité est à 0,7 plutôt qu’à 0,8. Pourquoi le jeu d’évaluation contient ces cinquante exemples et pas d’autres. Ces choix sortent de mois d’essais, et leur justification vit dans la mémoire de la personne qui les a faits.

Exemple vécu : un pipeline RAG qui tournait correctement, mais que personne d’autre que son auteur ne savait régler quand la qualité se dégradait. L’équipe pouvait le faire tourner ; elle ne pouvait plus le diagnostiquer. Un départ ne coûte alors pas seulement de la vélocité, il coûte la capacité de comprendre son propre produit. C’est une perte d’une autre nature que la dette technique classique, qui se chiffre et se négocie : ici, ce qui disparaît n’a jamais été dans le code.

Les signaux qui ne trompent pas

Certains indices reviennent dans presque tous les dossiers où le risque est réel. Une seule personne sait déployer. Les escalades de support finissent toutes sur le même téléphone. Les dernières vacances du CTO ont coïncidé avec un gel des mises en production. La documentation existe mais s’arrête dix-huit mois avant l’audit, à peu près au moment où l’équipe a doublé.

L’entretien avec le CTO est le meilleur révélateur : demandez le récit des trois dernières pannes sérieuses et notez qui apparaît dans chaque histoire. Quand le même prénom revient à chaque étape de chaque récit, la carte se dessine toute seule. Nous classons cette concentration parmi les signaux d’alerte sérieux, au même niveau que l’absence de tests et de revue de code, parce qu’elle conditionne tout le reste : la roadmap, le plan de création de valeur, et la valeur résiduelle en cas de départ.

Les clauses de rétention découlent de la carte

Sans carte, les acquéreurs traitent le risque homme-clé au forfait : un mécanisme de rétention standard pour tous les fondateurs, sur deux ou trois ans. C’est à la fois trop cher et insuffisant. Trop cher, parce qu’on retient des personnes que l’organisation saurait remplacer. Insuffisant, parce que la personne critique est parfois un ingénieur non fondateur, absent du montage, libre de partir avec un mois de préavis.

La carte permet un traitement ciblé. Des clauses de rétention dimensionnées pour les deux ou trois personnes réellement critiques. Un plan de transfert de savoir avec des jalons vérifiables : documentation des composants critiques, rotation des astreintes, binômage sur le pipeline. Et parfois un ajustement de prix, quand la concentration est extrême. Si la carte montre que le produit est inséparable de deux personnes, il faut le dire clairement : vous n’achetez pas un produit, vous recrutez une équipe avec un actif dedans. Ce n’est pas toujours une mauvaise affaire, à condition de la valoriser comme telle.

Cartographier ce risque demande de lire du code, des historiques et des gens, dans le temps court d’un deal. C’est l’un des livrables systématiques de notre audit technique, parce qu’aucune clause ne protège d’un risque qu’on n’a pas vu.