Due diligence technique : l’acheteur va aussi acheter vos problèmes

De l’autre côté de la table, chez Gridky, il y avait le CEO de l’acquéreur, le CTO du groupe et des cabinets payés pour chercher des risques. Personne n’y cherchait du beau code. On voulait savoir qui sait déployer, qui a écrit quoi et sous quel contrat, comment l’activité reprendrait après un incident majeur, quelles licences dorment dans les dépendances. Côté vendeur, j’ai surtout découvert ce que cet examen révélait de notre connaissance du produit.

Car l’acheteur reprend aussi des gens et des risques, et le dossier technique sert à lui prouver que vous savez ce que vous vendez. Le vendeur qui le sait négocie. Celui qui le découvre pendant l’examen subit.

J’ai fait l’exercice côté vendeur en tant que Head of Engineering chez Gridky, rachetée par Groupe Premium, puis dans une autre société où la cession n’a pas abouti : elle était rentable, les offres n’étaient pas à la hauteur, elle n’avait aucune raison de brader. Les deux fois, la préparation a pris environ un mois. Ce sont des cessions ; une levée de fonds donne un examen de la même famille, plus ou moins profond selon l’investisseur.

L’acheteur cherche à comprendre sur quelles personnes repose l’exploitation du produit. Les entretiens techniques permettent de vérifier que l’équipe sait expliquer l’architecture, les choix passés et les procédures de déploiement. Quand une seule personne détient ces connaissances, son départ pose une difficulté que la documentation doit aussi permettre d’évaluer.

Ce qui ressort des CV et des entretiens n’est pas une note, c’est une carte de qui tient quoi. Les développeurs parlent de bus factor ; l’acheteur dit « personne clé », avec une inquiétude de propriétaire.

Dans les opérations que j’ai connues, des contrats ont été réémis au nom de l’acquéreur, pour des salariés comme pour des freelances. Le renouvellement d’un contrat de freelance peut ouvrir une négociation, notamment lorsque le prestataire détient une connaissance difficile à transmettre. Je préfère savoir en janvier qui sera en position de force en juin que le découvrir le stylo à la main. En France, quand l’article L1224-1 du Code du travail s’applique, les contrats de travail en cours passent au nouvel employeur sans être renégociés. Les conséquences dépendent du montage de l’opération et doivent être examinées avec votre conseil.

La revue porte aussi sur la propriété du code. Pour chaque prestataire ayant contribué au produit, il faut retrouver le contrat et vérifier les dispositions relatives à la cession des droits. La due diligence technique rassemble ces éléments : qui a écrit quoi et sous quel contrat. Leur examen juridique revient aux conseils de l’opération.

Je me souviens de ma surprise : un composant s’installe en une ligne, puis des années plus tard il faut expliquer au cabinet d’audit ce que cette ligne engage. J’ai appelé ça une bombe amorcée dans la chaîne de valeur. Pour connaître les obligations exactes, il faut ensuite lire la licence et examiner l’intégration.

Open source ne veut pas dire libre de droits. Les licences permissives, MIT, BSD, Apache 2.0, prévoient notamment de conserver les mentions de copyright et le texte de la licence. Les licences à copyleft ajoutent des obligations de redistribution. Selon le projet GNU, celui qui redistribue un logiciel sous copyleft, modifié ou non, « doit aussi transmettre la liberté de le copier et de le modifier ». Un produit vendu à des clients, qui embarque un composant GPL, peut ainsi être tenu de fournir son propre code source sous la même licence à ceux qui le reçoivent. La portée de cette obligation demande un examen juridique de l’intégration.

L’usage en SaaS demande également une vérification des licences. L’AGPL vise notamment les interactions par le réseau. Son objectif, selon Wikipédia, est d’« obliger les services accessibles par le réseau de publier leur code source » lorsque le logiciel a été modifié.

L’inventaire doit donc préciser où chaque composant est utilisé et de quelle manière : outil de construction, bibliothèque intégrée au produit ou service exploité séparément. Ces informations permettent à un juriste spécialisé d’examiner les obligations applicables avant la revue de l’acheteur.

Un acheteur ne veut racheter ni une passoire ni un procès à venir. En reprenant la société, il reprend ses risques, et il le sait mieux que vous : c’est son métier. D’où trois questions qu’il pose toujours.

La conformité, d’abord. Au minimum le RGPD et la souveraineté des données : où elles sont hébergées, qui y accède, de quel droit relève chaque fournisseur. Il ne vous demande pas d’être parfait. Il vous demande de savoir.

La sécurité, ensuite. Il veut voir les mesures en place, les incidents passés et ce que vous en avez fait. C’est le point où les vendeurs se trompent de stratégie : ils cachent. Une faiblesse connue, documentée, en cours de correction, se défend. Une faiblesse que son cabinet découvre tout seul fait douter du reste du dossier, y compris de ce qui était vrai.

La continuité, enfin. Une procédure de reprise écrite ne le convainc pas ; une restauration de sauvegarde réellement faite, avec sa date et le temps qu’elle a pris, si.

Et puis il y a ce que personne ne pense à montrer : la dette, et les gestes manuels. L’acheteur préfère une dette que vous décrivez, avec un ordre de grandeur, à une dette qu’il devine en lisant le code : la première devient un chantier, la seconde un argument de prix. Quant aux tâches manuelles, la relance lancée à la main chaque semaine, l’export qu’une seule personne sait produire, le certificat noté dans un agenda, elles ne figurent dans aucune documentation et s’arrêtent le jour où la personne part. Elles font partie de ce qu’il achète ; il doit savoir qu’elles existent.

La même roadmap peut faire monter le prix ou le faire baisser.

Pour un actif mature dont il attend un revenu stable, l’acheteur examinera notamment le coût de maintenance et les investissements encore nécessaires. S’il cherche une société capable de changer d’échelle, il voudra comprendre comment la roadmap soutient cette croissance. Dans les deux cas, une fonctionnalité majeure peut être défendable : il faut montrer à quel objectif elle répond, avec quels moyens et quelles hypothèses de financement.

La plupart des roadmaps de PME que j’ai lues sont des listes de souhaits. Devant un acheteur, une liste de souhaits se retourne contre vous, parce qu’elle contredit ce que vous dites de votre dette et de vos moyens trois onglets plus loin. Une roadmap de due diligence se juge à sa cohérence avec le reste du dossier, pas à son ambition. La page sur la roadmap et les arbitrages produit explique comment construire des priorités qui tiennent ce test.

Un mois, les deux fois. Pas parce que les pièces sont nombreuses, mais parce qu’elles n’existent pas sous une forme lisible par un étranger. Il faut parcourir chaque dépôt pour retrouver la licence de chaque dépendance. Il faut croiser la facturation, les comptes ouverts et les intégrations présentes dans le code pour établir la liste des fournisseurs, parce qu’aucune de ces trois sources n’est complète seule (la méthode est détaillée dans Mon CTO est parti). Il faut écrire une documentation qu’un étranger comprendra, puis la confronter au produit réel.

Et ce mois se prend sur les épaules de ceux qui livrent, corrigent et répondent aux incidents. Les mêmes, toujours. La seule préparation qui coûte peu est celle qui a commencé avant, sous la forme de trois inventaires tenus au fil de l’eau.

La liste des dépendances s’extrait des fichiers de chaque projet, avec la licence déclarée par chacune : c’est ce que la CISA appelle un SBOM, un inventaire des composants d’un logiciel. L’extraction est la partie facile. Le travail commence après : repérer les licences à faire lire par un juriste, les composants abandonnés par leurs auteurs, les logiciels payants dont le contrat est au nom d’une personne plutôt que de l’entreprise.

Pour chaque fournisseur : qui détient le compte, qui paie, quelles données il reçoit, comment on le quitte. Un fournisseur présent dans la facturation mais absent de votre liste est un red flag, et l’acheteur se demande aussitôt ce qui manque encore. Un inventaire incomplet signalé comme tel se défend ; un inventaire présenté comme exhaustif puis démenti vous coûte votre crédibilité sur tout le reste. Un outil retiré du produit laisse souvent un compte ou une clé derrière lui : Les accès qui survivent aux outils montre comment vérifier leur retrait.

Les CV ne décrivent pas une équipe. Une carte des connaissances, qui associe chaque partie du système aux personnes capables d’y intervenir, en décrit une, et montre où le savoir est concentré, c’est-à-dire où l’acheteur va négocier. La documentation couvre l’architecture, le déploiement, l’exploitation et les choix structurants avec leurs raisons. Elle dit le vrai : une documentation écrite pour l’occasion, qui contredit le code, fait douter de tout.

Un taux de couverture seul est un chiffre pour rassurer un comité de direction. Il mesure le code que les tests exécutent, pas la pertinence de ce qu’ils vérifient. Présentez-le avec les zones couvertes, celles qui ne le sont pas, et la raison. Même règle pour un taux de disponibilité : sans périmètre ni méthode, un bon chiffre a l’air arrangé. Décrivez vous-même votre dette ; l’article sur le coût de la dette technique donne une manière d’en chiffrer l’ordre de grandeur. Et n’écrivez jamais « le produit est sécurisé et surveillé ». Montrez les alertes, qui les reçoit, et les incidents suivis.

Un dossier rempli de PDF peut rester impossible à examiner. Je veux pouvoir partir d’une affirmation, retrouver sa preuve, puis comprendre ce qui manque. Pour préparer cette lecture côté vendeur, je construirais une table de correspondance comme celle-ci. C’est une proposition de préparation, pas la liste contractuelle d’un cabinet d’audit.

Question à examiner	Pièces à relier	Ce qu’il reste à expliquer
Que rachète-t-on techniquement ?	Carte du produit, dépôts, architecture et intégrations	Périmètre couvert, dépendances externes et zones encore mal documentées
Qui peut faire tourner le produit ?	Carte des connaissances, procédures et accès de l’entreprise	Dépendance à une personne et passation encore nécessaire
Quels composants et fournisseurs utilisons-nous ?	Inventaires datés, licences, contrats et facturation	Écarts entre sources et points à faire examiner par les conseils
Comment reprend-on après un incident ?	Procédure, compte rendu du dernier test de restauration et incidents suivis	Ce qui a été rejoué, dans quel périmètre et ce qui ne l’a pas été
Que demandera la suite du produit ?	Roadmap, dette connue et hypothèses de charge	Arbitrages financés, dépendances et incertitudes restantes

Pour chaque pièce, je noterais un responsable, une date et un périmètre. Un document absent reste marqué absent. Un document ancien reste daté de sa rédaction : le renommer « version finale » ne le remet pas à jour.

Exemple fictif de constat : une procédure de restauration existe, mais aucun compte rendu de test n’est fourni. Le dossier permet d’affirmer que la procédure est écrite. Il ne permet pas d’affirmer que la reprise fonctionne, ni d’annoncer sa durée. La prochaine action est de convenir d’un test avec le responsable d’exploitation et d’en conserver le résultat. Je préfère cette ligne incomplète à un voyant vert sans pièce derrière : au moins, chacun sait ce qu’il reste à vérifier.

« Nous sommes certifiés. » « Nous avons un PCA. » Tant mieux, mais je demanderais encore les licences, la carte des connaissances et une restauration réellement rejouée. Ces pièces répondent à des questions différentes.

ISO/IEC 27001 est, selon l’ISO, une norme qui définit les exigences applicables à un système de management de la sécurité de l’information. Elle porte sur la gestion des risques de sécurité. L’examen des licences, de la maintenabilité du code et des connaissances de l’équipe demande d’autres éléments.

Selon le guide du SGDSN publié en 2013, le plan de continuité d’activité décline la stratégie et les dispositions prévues pour permettre à une organisation de reprendre et de poursuivre ses activités après un sinistre ou une perturbation grave. Il documente la préparation à ces situations, avec un objectif distinct de l’examen du code.

Le diagnostic technique et organisationnel que je propose peut aider à préparer l’opération en identifiant des risques et des priorités sur l’architecture, la dette, le delivery et l’équipe. Il conserve son propre périmètre : je n’interviens pas sur mandat de l’acheteur, et ces cinq jours ne remplacent ni les inventaires de licences et de fournisseurs ni un audit de code exhaustif.

La cession de Gridky a abouti. L’autre a échoué sur le prix. Je n’attribue pas ces issues au dossier technique ; un dossier ne vend pas une société. Il fait autre chose, qui compte autant : il décide de qui mène la discussion. Le vendeur qui connaît ses gens, ses licences et sa dette parle d’égal à égal avec le cabinet d’en face. Celui qui les découvre pendant l’examen répond à des questions, et chaque hésitation devient un argument de prix.

Sans attendre une opération, six inventaires suffisent à ne pas arriver les mains vides :

1. extraire les dépendances de chaque projet et leurs licences
2. croiser la liste des fournisseurs avec la facturation
3. lister les prestataires qui ont écrit du code et vérifier la cession de leurs droits
4. dresser la carte des connaissances de l’équipe
5. tester une restauration de sauvegarde, en notant sa date et sa durée
6. lister les tâches manuelles récurrentes

Si vous ne le faites pas, quelqu’un le fera pour vous, payé par l’acheteur, pendant que votre équipe devra aussi tenir sa roadmap. La page sur la gouvernance technique décrit ce qu’un dirigeant doit pouvoir suivre pour que ces inventaires existent sans crise, et le cas Gridky raconte le contexte technique de l’entreprise et le travail de stabilisation mené avec l’équipe.