Due diligence technique d'une application

Vous n'achetez pas une entreprise, vous achetez d'abord son code

Le chiffre d'affaires est dans le bilan, les contrats sont dans la data room, mais la valeur réelle d'une application se lit ailleurs : dans son code source, son infrastructure et l'équipe qui la maintient. C'est précisément ce qu'un acquéreur ou un investisseur découvre trop tard lorsqu'il a signé sans faire de due diligence technique.

Dans cet article, vous allez découvrir :

• •Ce que vérifie concrètement une due diligence technique, pilier par pilier, et ce qu'elle ne couvre pas
• •Qui doit la réaliser pour que le rapport soit crédible face au vendeur
• •Combien de temps et combien d'argent prévoir : de 2 500 euros HT en 5 jours à 12 000 euros HT en 3 semaines
• •Les 10 drapeaux rouges qui justifient une décote, un séquestre ou une condition suspensive

La valeur d'une application se lit dans son code. L'expert-comptable donne la valeur comptable, le banquier un multiple de chiffre d'affaires. La due diligence technique dit ce que l'actif vaut une fois le risque déduit.

Qu'est-ce qu'une due diligence technique ?

La due diligence technique (ou technical due diligence, due diligence IT, due diligence technologique, due diligence informatique selon les cabinets) est l'examen indépendant du code, de l'architecture, de la sécurité et de l'organisation technique d'une entreprise avant une acquisition, une levée de fonds ou un partenariat stratégique. Son objectif est de mesurer l'écart entre ce que le vendeur présente et ce que l'acquéreur achète réellement.

Elle intervient dans la même fenêtre que la due diligence financière et juridique, généralement entre la lettre d'intention et la signature. Elle répond à une question simple : cet actif logiciel vaut-il le prix demandé, et à quelles conditions ?

Ce qui la distingue d'un audit de code

Un audit de code s'adresse au propriétaire de l'application : il veut améliorer ce qu'il possède. La due diligence technique s'adresse à celui qui ne le possède pas encore : il veut décider s'il achète, à quel prix et avec quelles garanties. Les méthodes se recoupent, le livrable et la posture changent complètement.

Concrètement, l'auditeur en due diligence ne corrige rien. Il documente, il chiffre, il hiérarchise. Chaque constat est traduit en risque pour l'acheteur et, lorsque c'est possible, en impact sur le prix ou sur les clauses du contrat.

Les trois situations où elle est indispensable

1. 1.Acquisition d'une entreprise dont le logiciel est l'actif principal : SaaS, application mobile, plateforme, logiciel métier revendu à des clients.
2. 2.Levée de fonds ou entrée d'un investisseur : le fonds veut savoir si la roadmap promise est tenable avec le code existant.
3. 3.Rachat d'un logiciel interne ou d'une application métier : une entreprise reprend un outil développé par un prestataire ou un concurrent et doit savoir si elle pourra le faire vivre sans son équipe d'origine.

Ce que vérifie une due diligence technique : les 6 piliers

Une due diligence technique complète couvre six domaines, chacun avec ses propres questions et ses propres preuves. Un rapport qui n'en traite que deux ou trois (le code et la sécurité, le plus souvent) laisse des angles morts qui coûtent cher après le closing.

1. 1.Le code source : qualité, lisibilité, couverture de tests, taux de duplication, présence de code mort, volume et âge de la dette technique. On cherche à répondre à une question : combien de mois de travail faut-il pour rendre ce code sain, et combien ça coûte ?
2. 2.L'architecture et l'infrastructure : choix techniques, capacité à monter en charge, dépendance à un hébergeur ou à un service tiers, coûts d'exploitation réels, plan de reprise d'activité, monitoring.
3. 3.La sécurité : gestion des secrets, authentification, chiffrement des données, dépendances vulnérables, historique d'incidents, conformité RGPD. Un secret en clair dans le dépôt Git reste un classique.
4. 4.L'équipe et les process : qui connaît réellement le code, comment on livre en production, existe-t-il une intégration continue, une revue de code, une documentation à jour. L'application vaut-elle encore quelque chose si le développeur principal part le lendemain du closing ?
5. 5.La propriété intellectuelle et les licences : le code appartient-il bien à la société vendue (contrats des freelances, clauses de cession), quelles licences open source sont utilisées, y a-t-il des composants sous licence contaminante (GPL, AGPL) incompatibles avec un usage commercial.
6. 6.Le produit et les données : adéquation entre la roadmap annoncée et la faisabilité technique, qualité des données, dépendance à des API tierces, dette fonctionnelle (fonctionnalités développées mais jamais utilisées).

Les applications métier complexes sont parfaitement auditables sur ces six axes. L'application métier développée pour Dassault Aviation, avec ses 90+ utilisateurs actifs et ses 100+ fonctionnalités, illustre le type d'actif qu'un acquéreur doit faire examiner : volumineux, critique, et dont la valeur dépend autant de la qualité du code que du nombre de fonctionnalités.

Qui réalise une due diligence technique ?

La due diligence technique est réalisée par un tiers indépendant du vendeur et, idéalement, indépendant de l'acheteur : un cabinet spécialisé, une agence de développement expérimentée en audit, ou un CTO externe missionné pour l'occasion. L'indépendance est la condition pour que le rapport pèse dans la négociation.

Quatre profils se rencontrent sur le marché, avec des forces et des limites très différentes :

C'est ce qui fait la différence sur des applications techniques comme celle que nous avons conçue pour SNEF : l'application de visualisation de schémas électriques fait gagner 1h30 à ses utilisateurs tous les deux jours. Cette valeur d'usage est mesurable, mais elle ne se lit qu'en comprenant ce que fait le code, pas en comptant les lignes.

À lire aussi : Audit de code source : ce que nous y trouvons - La méthode ONDEV pour lire une base de code en profondeur, du dépôt Git au déploiement en production.

Combien de temps et combien coûte une due diligence technique ?

Une due diligence technique dure entre 5 jours et 3 semaines et coûte entre 2 500 et 12 000 euros HT selon la taille de la base de code, le nombre de services et le niveau de détail attendu par l'acquéreur. Ces fourchettes sont celles que nous appliquons sur notre page due diligence technique ; elles ne comprennent pas les corrections éventuelles, qui relèvent d'une mission distincte.

• •Le volume et l'âge du code : une application de 10 ans avec plusieurs générations de développeurs demande plus de temps qu'un SaaS de 18 mois.
• •Le nombre de composants : chaque application mobile, chaque microservice, chaque base de données ajoute un périmètre d'analyse.
• •L'accès à l'équipe : les entretiens avec les développeurs raccourcissent l'analyse ; un vendeur qui les refuse allonge la mission et constitue déjà un signal.

Rapporté au ticket, l'ordre de grandeur est parlant : une due diligence complète à 10 000 euros HT sur une acquisition à 2 millions d'euros représente 0,5 % du prix. La moindre décote qu'elle justifie la rembourse plusieurs fois.

Ce que contient le rapport de due diligence technique

Le rapport de due diligence technique est un document de 20 à 60 pages qui synthétise les constats par pilier, les hiérarchise par gravité et les traduit en recommandations pour la négociation. Un bon rapport se lit à deux niveaux : la synthèse exécutive pour le dirigeant et le fonds, le détail technique pour le CTO qui reprendra l'application.

Sa structure type comporte sept parties :

1. 1.La synthèse exécutive : verdict en une page, note de risque globale, trois à cinq points qui changent la décision.
2. 2.Le périmètre et la méthode : ce qui a été examiné, ce qui ne l'a pas été, les accès obtenus et refusés.
3. 3.Les constats par pilier : code, architecture, sécurité, équipe, licences, produit, chacun avec son niveau de gravité (bloquant, majeur, mineur).
4. 4.Le chiffrage de la remise à niveau : en jours de développement et en euros, poste par poste.
5. 5.Le plan de transition : ce qu'il faut sécuriser dans les 90 jours suivant le closing.
6. 6.Les recommandations de négociation : ce que chaque constat change au prix ou au contrat.
7. 7.Les annexes : résultats d'outils, inventaire des dépendances, cartographie de l'infrastructure.

La sixième partie est celle que les acquéreurs sous-estiment le plus. Chaque constat sérieux se traduit par un levier concret :

• •une décote sur le prix, calée sur le coût de remise à niveau chiffré ;
• •un séquestre d'une partie du prix, libéré une fois les corrections livrées ;
• •une garantie de passif élargie au périmètre technique (incidents de sécurité, licences) ;
• •un earn-out conditionné à la tenue de la roadmap technique ;
• •une condition suspensive lorsque le risque est bloquant (code non détenu, faille non corrigée).

Les 10 drapeaux rouges d'une due diligence technique

Un drapeau rouge est un constat qui, à lui seul, doit faire renégocier le prix ou suspendre la transaction. Voici les dix que nous rencontrons le plus souvent, par ordre de gravité décroissant.

1. 1.La propriété du code n'est pas établie : freelances sans clause de cession, code écrit par un ancien associé parti fâché, prestataire qui conserve les accès au dépôt. Sans propriété claire, il n'y a rien à acheter.
2. 2.Une personne unique détient la connaissance : le fondateur ou un développeur historique est le seul à savoir déployer, corriger ou expliquer l'architecture. Sa démission est un risque de continuité d'activité.
3. 3.Des secrets en clair dans le code : clés d'API, mots de passe de base de données ou certificats commités dans Git, parfois dans l'historique accessible à tous les anciens collaborateurs.
4. 4.Aucun test automatisé : chaque évolution est un pari. Le coût de toute modification future est multiplié, la roadmap promise est fictive.
5. 5.Des dépendances obsolètes ou abandonnées : framework en fin de vie, bibliothèques non maintenues depuis des années, versions de langage sans correctifs de sécurité.
6. 6.Un déploiement manuel et non reproductible : la production n'est pas descriptible dans le code, l'environnement ne peut pas être recréé, les sauvegardes n'ont jamais été testées.
7. 7.Une licence open source incompatible : composant sous GPL ou AGPL intégré dans un produit commercial propriétaire, exposant l'acquéreur à une obligation de publication du code.
8. 8.Un écart entre la démo et la production : fonctionnalités présentées comme livrées mais inexistantes ou inutilisables, chiffres d'usage impossibles à vérifier dans les logs.
9. 9.Une dette technique non documentée et non chiffrée : le vendeur sait que le code est fragile mais n'a jamais mesuré le coût de sa remise à niveau. Cette dette, c'est l'acheteur qui la paiera.
10. 10.Des données personnelles mal protégées : absence de chiffrement, logs contenant des données clients, pas de registre des traitements. Le risque est réglementaire autant que réputationnel.

Un seul de ces dix points justifie d'ouvrir la négociation. Trois ou plus posent la question de la poursuite du deal, ou au minimum d'une condition suspensive sur leur correction.

Les erreurs classiques des acquéreurs

La principale erreur est de lancer la due diligence technique trop tard, une fois le prix fixé et la lettre d'intention signée avec une exclusivité courte. L'auditeur travaille alors sous pression de calendrier et ses constats n'ont plus de poids dans la négociation.

Trois autres erreurs reviennent systématiquement :

• •Confier l'audit au CTO interne : il manque de temps, il est en conflit d'intérêts (il devra vivre avec ce code) et son avis n'a aucune valeur probante face au vendeur.
• •Se contenter d'un rapport d'outil automatique : une analyse statique produit des milliers d'alertes sans hiérarchie. Elle ne dit pas ce qui compte, ni ce que ça coûte.
• •Ignorer la partie équipe : le code le plus propre du monde ne vaut rien si personne ne reste pour le maintenir après la vente.

À l'inverse, les acquéreurs qui obtiennent les meilleures conditions ont une habitude commune : ils font auditer avant de fixer le prix, pas après.

FAQ : vos questions sur la due diligence technique

Une fois l'acquisition conclue, le rapport devient une feuille de route : notre service de refonte d'application web reprend les chantiers identifiés dans l'ordre des risques, sans interrompre le service aux utilisateurs.

Conclusion : auditez avant de signer, pas après

La due diligence technique n'est pas une formalité de plus dans la data room. C'est le seul exercice qui dit ce que vaut réellement l'application que vous achetez, une fois le risque technique déduit. Six piliers, un rapport qui chiffre et hiérarchise, dix drapeaux rouges qui pèsent sur le prix : vous savez maintenant ce qu'il faut exiger.

Chez ONDEV, nous lisons et exécutons le code que nous auditons, parce que nous passons nos journées à en écrire et à en reprendre : c'est ce qui nous permet de chiffrer un constat en jours de développement, pas seulement de le décrire.

Vous préparez une acquisition, une levée de fonds ou le rachat d'un logiciel métier ? Parlons de votre due diligence technique : nous vous disons en un échange quel format convient à votre deal et sous quel délai nous pouvons intervenir.