La due diligence technique n’est pas un concours de qualité de code, et les équipes qui s’y préparent consacrent en général leur temps à la mauvaise chose. Personne, en rachetant une société, ne vient noter vos abstractions. L’acquéreur cherche à établir ce que coûtera la possession de ce système, et à quel point les choses peuvent mal tourner une fois l’argent versé.

Ce changement de cadrage compte, parce qu’il change ce qu’il faut corriger en premier. Du code laid qui fonctionne, que l’équipe comprend et que l’on peut modifier sans danger, reste un constat mineur. Du code élégant qu’une seule personne comprend est un constat sérieux, et c’est le second qui déplace le prix.

La question derrière toutes les questions : si l’ingénieur fondateur part la semaine suivant la réalisation de l’opération, ce système continue-t-il de tourner et de pouvoir évoluer ? Presque tous les constats qui font baisser une offre répondent précisément à cela. Une connaissance concentrée sur une seule tête, un déploiement non documenté, des licences que personne n’a vérifiées, des accès qui n’existent que dans la mémoire d’une personne.

Ce que la due diligence technique évalue réellement

Quatre risques, à peu près dans l’ordre où ils pèsent sur la valorisation.

Le risque de dépendance à une personne clé. Savoir si le système repose sur des individus plutôt que sur un processus documenté. C’est régulièrement le constat le plus destructeur, parce qu’il est le plus difficile à corriger après coup et qu’il menace directement ce que l’on achète.

Le coût de la continuation. Ce qu’il faut pour maintenir le système en marche et le faire évoluer : dépenses d’infrastructure, obligations de licence, taille de l’équipe nécessaire, et part de la feuille de route qui sera absorbée par la maintenance plutôt que par du travail nouveau.

La responsabilité juridique. Des licences incompatibles avec un usage commercial, des données personnelles traitées d’une façon qui ne résisterait pas à une réclamation, une exposition en matière de sécurité, et toute obligation réglementaire que la société ne respecte pas réellement.

La capacité à changer. Savoir si de nouvelles fonctionnalités peuvent être livrées à un rythme prévisible, ou si chaque modification risque de casser quelque chose qui n’a aucun rapport.

La qualité du code ne compte qu’à travers ce quatrième point, et c’est pourquoi un évaluateur passera moins de temps à lire votre code que les fondateurs ne l’imaginent, et davantage à demander comment se déroulent vos déploiements.

Les constats qui font baisser le prix

Une seule personne sait déployer. Un processus de mise en production qui vit dans la tête de quelqu’un, ou sur son ordinateur portable, est traité comme un risque opérationnel sérieux, quelle que soit son efficacité aujourd’hui.

Aucune couverture de tests sur les chemins qui comptent. Il ne s’agit pas d’un pourcentage de couverture, que les évaluateurs ignorent largement, mais de savoir si le système peut être modifié avec la moindre confiance. Une base de code sans tests autour du parcours de revenus fait intégrer au prix une feuille de route plus lente. Notre guide des stratégies de test logiciel détaille ce qui mérite vraiment sa place.

La contamination par les licences. Du code copyleft à l’intérieur d’un produit propriétaire est l’un des rares constats capables d’arrêter une opération au lieu de simplement la repricer, et un scanner le trouve en quelques minutes.

Des données personnelles sans base défendable. Des données collectées sans base légale claire, conservées indéfiniment, ou stockées à des endroits que la société est incapable d’énumérer. Les mécanismes de la conformité technique au RGPD sont exactement ceux qu’un évaluateur vérifie.

Des dépendances non documentées envers des personnes ou des prestataires. Une intégration critique avec un fournisseur sans contrat, ou une infrastructure hébergée sur un compte personnel : les deux se lisent comme un risque non maîtrisé.

Les fondamentaux de sécurité absents. Il ne s’agit pas du résultat d’un test d’intrusion, mais de savoir si des secrets sont dans le dépôt de code, si les accès sont retirés quand les gens partent, et si quelque chose d’exposé sur Internet reste actuellement non corrigé.

Ce dont les évaluateurs se moquent

Cela mérite d’être dit, car le temps de préparation est limité et il est presque toujours mal employé.

Le framework que vous avez choisi n’intéresse personne, tant que l’on peut recruter des gens qui le connaissent. La mode architecturale n’intéresse pas davantage : un monolithe qui livre n’est pas un constat. Le style de code, les conventions de nommage ou l’absence d’un motif recommandé par quelqu’un sur Internet ne pèsent rien.

Personne n’attend non plus une dette technique nulle. Toutes les sociétés en ont, et sa présence est normale. Ce qui compte, c’est de savoir si l’équipe sait où elle se trouve et peut décrire ce qu’elle coûte. Une équipe qui produit une liste claire de ses propres problèmes connus passe pour compétente. Une équipe qui affirme n’en avoir aucun passe pour inconsciente, et l’évaluateur doit alors les trouver seul, ce qui prend plus de temps et donne un compte rendu moins favorable.

Se préparer sans rien réécrire

L’essentiel de ce qui aide se compte en jours, pas en mois, et rien de tout cela ne touche à l’architecture.

Écrivez comment déployer. Depuis une machine vide jusqu’à un système en fonctionnement. Ce seul document traite la catégorie de constats la plus destructrice, et il s’écrit en un après-midi.

Énumérez vos dépendances et leurs licences. L’outillage automatisé produit cette liste rapidement, et connaître la réponse avant l’évaluateur vaut nettement plus qu’un résultat parfaitement propre.

Sortez les secrets du dépôt de code et inventoriez qui a accès à quoi. Retirez ensuite les accès de toutes les personnes qui sont parties.

Documentez ce que vous savez défaillant. Un registre court et honnête des problèmes connus, avec une estimation grossière du coût de remise en état. Le fournir spontanément est l’une des rares choses qui améliorent de façon fiable la tonalité d’un rapport.

Assurez-vous que l’infrastructure appartient à la société, et non à un compte individuel, et que les noms de domaine, les certificats et les dépôts sont tous sous contrôle de l’entreprise.

Ce que deviennent les constats

Ils tuent rarement une opération. Ils deviennent des conditions.

Les constats se résolvent en général de trois façons : un ajustement de prix reflétant le coût de remise en état, une garantie ou une clause d’indemnisation dans le contrat, ou une condition à satisfaire avant la réalisation. Seules la contamination par les licences et une exposition grave et non traitée en protection des données arrêtent régulièrement une transaction pour de bon.

L’objectif pratique n’est donc pas un système parfait. C’est un système dont les problèmes sont connus, bornés et descriptibles, parce qu’un problème chiffré se négocie alors qu’un problème non chiffré est présumé pire qu’il ne l’est.

Mecanik réalise ce type de revues techniques dans le cadre de son activité de développement logiciel , le plus souvent du côté de l’acheteur. Le schéma est stable : les systèmes qui passent bien une revue ne sont pas les plus sophistiqués, ce sont ceux où quelqu’un a pris la peine d’écrire les choses.

À lire aussi : Software escrow : qui en a réellement besoin , Développement logiciel fintech au Royaume-Uni : FCA, rails et coûts , Contrat au forfait ou en régie ? et Développement logiciel sur mesure au Royaume-Uni : le guide complet de l’acheteur .

Questions fréquentes

Qu’est-ce que la due diligence technique ? Une évaluation de ce que coûtera la possession d’un système logiciel et de la gravité de ce qui peut mal tourner après une acquisition ou un investissement. Elle examine le risque de dépendance à une personne clé, le coût de la continuation, la responsabilité juridique et la capacité à faire évoluer le système, plutôt que de noter la qualité du code pour elle-même.

Quels constats font le plus baisser le prix ? La concentration de la connaissance sur des individus, en particulier un processus de déploiement qu’une seule personne sait exécuter. Ensuite : aucune couverture de tests utile sur les parcours de revenus, une contamination par du code copyleft dans un produit propriétaire, des données personnelles sans base légale défendable, et des secrets versés dans le dépôt de code.

Les évaluateurs se soucient-ils de ma dette technique ? Ils s’y attendent. Toutes les sociétés en ont et sa présence n’est pas un constat. Ce qui compte, c’est de savoir si l’équipe sait où elle se trouve et peut décrire ce que sa correction coûterait. Un registre clair des problèmes connus se lit comme une preuve de compétence ; affirmer qu’il n’y en a aucun se lit comme de l’inconscience et rend la revue plus sévère.

Comment se préparer à une due diligence technique ? Écrivez comment déployer le système depuis une machine vide, énumérez les dépendances et leurs licences, retirez les secrets du dépôt de code, vérifiez qui dispose encore d’un accès, confirmez que l’infrastructure et les noms de domaine appartiennent à la société et non à des individus, et produisez un registre honnête des problèmes connus avec une estimation grossière du coût de correction.

Un constat technique peut-il arrêter complètement une opération ? Rarement. La plupart des constats deviennent des ajustements de prix, des garanties dans le contrat, ou des conditions à satisfaire avant la réalisation. Les exceptions qui arrêtent vraiment une transaction sont la contamination par une licence copyleft dans un produit propriétaire et une exposition grave et non traitée en protection des données.