Préparer une due diligence technique : ce qu'un fonds cherche vraiment
Un audit technique ne note pas votre code comme une copie d'examen. Il chiffre un risque, celui que la technologie devienne le facteur limitant des dix-huit mois que l'investisseur s'apprête à financer. Cette nuance change entièrement ce qu'il faut préparer, et elle explique pourquoi la catégorie qui fait vraiment reculer un fonds n'est presque jamais la qualité du code.
By John-Guy Park · · 10 min de lecture
Key facts
- Un audit technique ne cherche pas un code parfait. Il chiffre la probabilité que la technique ralentisse le plan de croissance qu'on est en train de financer.
- Étude Stripe et Harris Poll « The Developer Coefficient » (2018) : un développeur consacre plus de 17 heures par semaine à la maintenance, et environ 4 heures de plus à corriger du « mauvais code ».
- La dépendance à une seule personne est le seul axe qu'aucun sprint de trois semaines ne rattrape avant la restitution. Elle se travaille six mois à l'avance.
- Cinq métriques suffisent à objectiver la capacité de livraison : délai de mise en production, fréquence de déploiement, temps de rétablissement, taux d'échec et taux de reprise des déploiements (référentiel DORA, Google Cloud).
- En France, une cession de droits sur du code est fragile si chaque droit cédé ne fait pas l'objet d'une mention distincte et si le domaine d'exploitation n'est pas délimité (article L131-3 du Code de la propriété intellectuelle).
- Le registre des activités de traitement est obligatoire pour tout organisme traitant des données personnelles, quelle que soit sa taille (article 30 du RGPD, doctrine CNIL).
Un audit technique ne note pas votre code, il chiffre un risque
La plupart des fondateurs abordent une due diligence technique comme un examen de propreté. Ils passent trois semaines à supprimer des commentaires, à renommer des variables et à écrire des tests pour faire monter un pourcentage de couverture. C'est un effort presque entièrement gaspillé, parce que ce n'est pas la question posée.
La question posée est financière. Un investisseur ne finance pas un trou de trésorerie, il finance une accélération, et il veut savoir si la technique va suivre cette accélération ou la freiner. Personne, dans une équipe d'investissement, n'attend d'une jeune société qu'elle ait une base de code irréprochable. Ce qu'on cherche à savoir, c'est combien des dix-huit prochains mois vont partir en remboursement de dette plutôt qu'en fonctionnalités qui font croître le chiffre d'affaires.
Le mécanisme par lequel la dette technique devient un problème de calendrier est bien documenté. L'étude « The Developer Coefficient », menée par Stripe avec Harris Poll auprès de milliers de dirigeants et de développeurs, mesure qu'un développeur consacre plus de 17 heures par semaine à des tâches de maintenance, débogage et refactorisation compris, auxquelles s'ajoutent environ 4 heures passées à corriger du code de mauvaise qualité. Ce sont des heures qui ne produisent pas de produit. Sur une équipe de six personnes, cela pèse davantage sur la feuille de route que n'importe quelle décision d'architecture.
D'où la conclusion contre-intuitive : avoir de la dette technique ne fait échouer aucun audit. Ne pas savoir combien on en a, en revanche, en fait échouer beaucoup. Une équipe capable de dire « voici nos quatre chantiers de dette, voici ce que chacun coûte en semaines-homme, voici lequel bloquerait un passage à cent mille utilisateurs » démontre exactement la maîtrise qu'on cherche à vérifier. Une équipe qui répond « le code est plutôt propre » vient d'annoncer qu'elle ne mesure rien.
C'est ce déplacement du regard qui structure notre méthode d'audit technique indépendant : nous ne produisons pas une note de qualité, nous produisons un chiffrage de ce qu'il faudra dépenser pour tenir le plan présenté.
La dépendance à une seule personne ne se rattrape pas en trois semaines
Il existe une scène classique en salle d'audit. Le développeur principal est brillant. Il répond à chaque question sans hésiter, déroule l'architecture de mémoire, défend chaque choix technique avec une aisance impressionnante. Les fondateurs sortent de la réunion convaincus d'avoir marqué des points. L'investisseur, lui, vient de reculer, et précisément à cause de cette performance.
Ce qu'il a compris en regardant un virtuose expliquer de tête un système que personne n'a documenté, c'est que la fonction technique de l'entreprise n'est pas une fonction, c'est une personne. Si elle part, si elle tombe malade, si elle négocie, la valeur de l'actif change du jour au lendemain. Aucun autre risque identifié pendant un audit n'a cette propriété de tout emporter d'un coup.
Ce risque se réduit, mais lentement, et par des gestes précis. Il faut qu'une deuxième personne ait réellement déployé en production, pas seulement lu la documentation. Il faut que les décisions d'architecture soient écrites quelque part, avec leur raison, parce que c'est le raisonnement qui se perd et pas le schéma. Il faut qu'un recrutement récent ait été intégré sans que le développeur principal soit mobilisé à plein temps, ce qui est la seule preuve vérifiable que l'intégration fonctionne. Chacun de ces gestes prend des mois.
C'est aussi la raison pour laquelle un CTO fractionné améliore mécaniquement une note d'audit, même à un ou deux jours par semaine. Non pas parce qu'il écrit du meilleur code, mais parce qu'une deuxième personne expérimentée connaît le système, que les décisions passent par un écrit, et que le fondateur cesse d'être le seul interlocuteur crédible sur les sujets techniques.
Notre conseil, sans détour : si une levée est envisagée dans l'année, cet axe est le premier à traiter, et c'est le seul qu'il est déjà trop tard pour traiter quand le fonds annonce la date de l'audit.
Cinq chiffres qui remplacent trois heures de discussion
Une grande partie des audits techniques se passe en conversation, et la conversation favorise ceux qui parlent bien. C'est un mauvais protocole pour les deux parties. Il existe pourtant un jeu de mesures largement admis qui transforme la question « est-ce que vous livrez bien » en données comparables : les métriques de performance de livraison du programme DORA, désormais rattaché à Google Cloud.
Elles se lisent en deux familles. Le débit se mesure par le délai de mise en production d'un changement, depuis le moment où il est versé jusqu'à sa mise en ligne, par la fréquence de déploiement, et par le temps nécessaire pour se rétablir d'un déploiement raté. La stabilité se mesure par le taux de déploiements qui exigent une intervention immédiate, correctif à chaud ou retour arrière, et par le taux de déploiements non planifiés provoqués par un incident en production.
L'intérêt de ces cinq nombres n'est pas de vous classer. Il est de déplacer la discussion d'un terrain d'opinion vers un terrain de fait, et d'apporter ces chiffres soi-même plutôt que de les subir. Une équipe qui arrive avec six mois d'historique sur ces mesures fixe le cadre de l'échange, et l'audit se met à porter sur les vraies questions plutôt que sur la crédibilité de l'équipe.
Une réserve honnête, parce que ces indicateurs sont faciles à détourner : on peut gonfler une fréquence de déploiement en découpant artificiellement des livraisons, et faire baisser un taux d'échec en cessant de déclarer les incidents. Un auditeur expérimenté croise ces chiffres avec l'historique du dépôt de code et avec les comptes rendus d'incidents. Mesurer pour comprendre fonctionne, mesurer pour se présenter se voit.
Les deux angles juridiques que les fondateurs découvrent trop tard
Le premier est la propriété du code, et c'est celui qui provoque le plus de mauvaises surprises. Beaucoup de jeunes sociétés ont fait développer une partie de leur produit par des indépendants ou des prestataires, avec un bon de commande décrivant une prestation mais sans clause de cession de droits sérieuse. En droit français, la transmission des droits d'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession, et que le domaine d'exploitation soit délimité quant à son étendue, sa destination, le lieu et la durée. C'est l'article L131-3 du Code de la propriété intellectuelle, et il ne se contourne pas par une facture acquittée.
La conséquence pratique est brutale : une société peut découvrir pendant un audit qu'elle n'est pas propriétaire d'un morceau de son propre produit, et que la personne qui l'est n'a plus aucune raison d'être coopérative. La régularisation est possible, mais elle dépend entièrement de la bonne volonté d'anciens prestataires, ce qui en fait une négociation et non une formalité. C'est pour cette raison que nous transférons la propriété du code dès le premier euro facturé, sans clause de réserve : c'est une contrainte pour nous et une ligne de moins à défendre pour nos clients.
Le second angle est le traitement des données personnelles, et il est souvent traité comme un sujet de mentions légales alors qu'il figure dans les questionnaires d'audit. Le registre des activités de traitement est obligatoire pour tout organisme qui traite des données personnelles, publiques ou privées, quelle que soit sa taille, en application de l'article 30 du RGPD. La CNIL rappelle qu'il faut une fiche par activité de traitement. Une jeune société qui n'a aucun registre ne signale pas un manquement grave, mais elle signale qu'un sujet réglementaire n'a jamais été instruit, et l'auditeur se demande alors ce qui n'a pas été instruit non plus ailleurs.
Un troisième point, technique celui-là, mérite le même traitement anticipé : l'inventaire des composants tiers et de leurs versions. La catégorie A06:2021 du référentiel OWASP Top 10, « Vulnerable and Outdated Components », insiste sur le fait de connaître et d'inventorier l'ensemble des bibliothèques et dépendances utilisées ainsi que leurs versions. Ne pas pouvoir produire cette liste est un signal désagréable, et c'est aussi l'un des rares points de cette page qui se corrige réellement en quelques semaines.
Ces trois vérifications ne demandent aucune compétence rare. Elles demandent d'y avoir pensé avant, ce qui est exactement ce qu'un audit de cadrage permet de faire à froid, et ce que nos tarifs affichent sans devis à rallonge.
Les six axes d'un audit, et le temps réel pour corriger chacun
| Axe examiné | Ce qui rassure un investisseur | Ce qui l'inquiète | Délai de correction |
|---|---|---|---|
| Dette technique | Une dette identifiée, chiffrée en semaines-homme et planifiée | Une dette dont personne ne connaît le volume | 1 à 3 mois pour la cartographier |
| Dépendance aux personnes | Deux personnes au moins ont déployé en production | Une seule personne répond à toutes les questions | 6 mois et plus |
| Capacité de livraison | Les cinq métriques DORA mesurées depuis six mois | « On livre vite », sans aucun chiffre à l'appui | 3 à 6 mois d'historique à constituer |
| Composants tiers | Un inventaire des dépendances et de leurs versions | Des dépendances non maintenues et non recensées | 2 à 6 semaines |
| Propriété du code | Des cessions écrites conformes à l'article L131-3 | Des prestataires passés sans clause de cession | 1 à 3 mois, si les prestataires répondent |
| Données personnelles | Un registre des traitements à jour, une fiche par activité | Aucun registre, aucune base légale documentée | 4 à 8 semaines |
Frequently asked questions
Combien de temps dure une due diligence technique ?
Le travail d'analyse tient généralement en deux à trois semaines, entretiens et restitution écrite comprise. La partie visible pour l'équipe est beaucoup plus courte : quelques heures de lecture documentaire, deux à quatre heures d'examen du code et un à deux entretiens avec le responsable technique. Ce qui allonge un audit n'est presque jamais la technique, c'est le temps qu'il faut pour obtenir les accès, les contrats de prestation et les comptes rendus d'incidents. Une société qui a préparé ces documents raccourcit l'exercice de plusieurs jours.
Faut-il nettoyer le code avant l'audit ?
Non, et un grand nettoyage de dernière minute produit souvent l'effet inverse de celui recherché. L'historique du dépôt de code est visible : une vague de modifications cosmétiques dans les trois semaines précédant un audit se lit immédiatement et attire l'attention sur ce qu'on a voulu masquer. Le temps est bien mieux investi à écrire ce qui manque : un schéma d'architecture à jour, la liste chiffrée des chantiers de dette, l'inventaire des dépendances. Ces documents rassurent un auditeur beaucoup plus qu'un code fraîchement reformaté.
Un investisseur va-t-il vraiment lire notre code source ?
Rarement lui-même, et jamais en totalité. Il mandate un tiers technique, qui échantillonne : les zones les plus modifiées, les points d'entrée exposés, la couche d'accès aux données, la gestion des secrets et de l'authentification. L'objectif n'est pas de tout lire mais de vérifier si ce que l'équipe affirme correspond à ce que le code montre. Une divergence entre le discours et le dépôt de code pèse bien plus lourd qu'un défaut de qualité assumé.
Que se passe-t-il si l'audit révèle un problème sérieux ?
Dans la majorité des cas, le deal ne s'arrête pas, il se renégocie. Un risque chiffré se traduit par un ajustement de valorisation, par une tranche conditionnée à des étapes techniques, ou par des clauses de garantie plus serrées. Ce qui casse réellement une opération, c'est la découverte tardive d'un élément que les fondateurs connaissaient et n'avaient pas signalé, parce que cela déplace le problème du terrain technique vers le terrain de la confiance. Mieux vaut annoncer soi-même un point faible et arriver avec son plan de correction chiffré.
Combien coûte une due diligence technique ?
Chez nous, un audit et cadrage coûte 4 900 €, avec une restitution écrite en deux semaines, et nous rendons un devis sous cinq jours ouvrés. Le prix du marché varie surtout selon le périmètre : auditer un produit unique avec une équipe de cinq personnes n'a rien à voir avec un groupe qui exploite huit applications héritées. Le bon repère n'est pas le tarif journalier mais le livrable : un audit qui se termine par une présentation orale sans document écrit ne vous sert à rien dans une négociation, puisque vous ne pourrez ni le transmettre ni l'opposer.
Peut-on faire auditer sa propre technique avant d'aller voir des fonds ?
C'est l'usage que nous recommandons le plus, et de loin. Un audit commandé par vous, six à neuf mois avant une levée, vous donne le temps de corriger ce qui se corrige et de préparer un discours honnête sur ce qui ne se corrigera pas. Il change aussi la position dans la négociation : vous arrivez avec un document qui identifie les faiblesses avant que l'investisseur ne les trouve, ce qui est le signal de maturité le plus efficace qu'une équipe technique puisse envoyer. L'inconvénient est qu'un audit à charge contre vous-même est inconfortable à lire.
Notre responsable technique doit-il assister à l'audit ?
Oui, mais il ne doit pas être le seul à parler, et c'est un point de préparation à part entière. Si toutes les réponses viennent d'une seule personne, l'audit conclura mécaniquement à une dépendance forte, quelle que soit la qualité des réponses. Faites intervenir un deuxième profil sur au moins un volet, la mise en production ou la gestion des incidents par exemple. L'objectif n'est pas de mettre en scène une équipe plus étoffée qu'elle n'est, mais de montrer que la connaissance circule réellement.
Sources cited
- Stripe et Harris Poll — The Developer Coefficient (septembre 2018) — plus de 17 heures par semaine consacrées à la maintenance, dont débogage et refactorisation, plus environ 4 heures sur du « mauvais code »
- DORA (Google Cloud) — Software delivery performance metrics — définition des cinq métriques : délai de mise en production, fréquence de déploiement, temps de rétablissement, taux d'échec et taux de reprise
- OWASP Top 10 (2021) — A06 Vulnerable and Outdated Components — nécessité de connaître et d'inventorier l'ensemble des composants utilisés ainsi que leurs versions
- Code de la propriété intellectuelle — article L131-3 — mention distincte de chaque droit cédé et délimitation du domaine d'exploitation quant à l'étendue, la destination, le lieu et la durée
- CNIL — Le registre des activités de traitement — obligation issue de l'article 30 du RGPD, applicable à tout organisme quelle que soit sa taille, une fiche par activité de traitement
Got a project to turn into a product?
Book 30 minutes, or describe your idea in a few lines. We reply within 5 business days with free scoping — scope, risks, timeline and engagement pricing.