Due diligence technique d'une startup: la checklist avec les critères

Les checklists de due diligence technique qui circulent ont toutes le même défaut : elles listent les questions, jamais les réponses. « Évaluer l’architecture », « examiner la dette technique » : soit, mais qu’est-ce qui distingue une architecture qui mérite 5 d’une architecture qui mérite 1 ? Après des années à ouvrir du code, le nôtre comme celui des autres, voici les 6 axes et, pour chacun, les critères concrets qui font basculer le verdict.

À quoi sert une due diligence technique, exactement ?

À vérifier que la valeur annoncée d’une entreprise repose sur un actif logiciel réel, sain et transférable. La due diligence, ou audit d’acquisition, désigne l’ensemble des vérifications qu’un investisseur ou un repreneur mène avant d’engager ses fonds, pour faire ressortir les forces et les faiblesses de la cible et alimenter la négociation (Bpifrance Création, l’audit d’acquisition). Le volet technique en est devenu le cœur pour les startups : quand l’essentiel de la valeur est un logiciel, auditer la comptabilité sans auditer le code revient à acheter une maison sur la foi de sa boîte aux lettres.

Le résultat utile n’est pas une note, c’est une cartographie chiffrée : ce qui est sain, ce qui est réparable et à quel coût, ce qui constitue un risque réel pour la transaction. Un code imparfait n’a jamais fait échouer une levée ; un risque découvert après la signature, si.

Quels sont les 6 axes à auditer, et avec quels critères ?

Voici la grille complète, avec ce qui fait concrètement un bon et un mauvais score sur chaque axe :

La pondération des axes dépend du stade, et c’est ce que les grilles génériques oublient. En pré-seed, exiger une architecture parfaitement scalable est un contresens : on audite la lucidité de l’équipe sur ses raccourcis, la propriété du code et le bus factor, parce que ce sont eux qui conditionnent la suite. En série A, les tests, le déploiement et la sécurité montent en exigence : l’argent levé sert à accélérer, et on n’accélère pas sur des fondations que personne n’ose toucher. Pour un rachat, tout pèse, avec un accent sur la transférabilité : l’acquéreur doit pouvoir opérer sans les fondateurs. Le même constat peut donc être anodin à un stade et bloquant à un autre : un rapport sérieux le précise, un rapport générique non.

Trois de ces axes méritent un développement, parce que ce sont eux qui tuent les transactions.

La propriété intellectuelle d’abord, le piège le plus sous-estimé. En droit français, payer une prestation de développement ne transfère pas les droits sur le code : sans acte de cession écrit respectant le formalisme du code de la propriété intellectuelle, le prestataire conserve ses droits d’auteur, et le problème éclate précisément au moment de la due diligence (Atias Avocats, propriété du code source). Une startup dont le MVP a été construit par trois freelances sans contrat de cession ne possède pas juridiquement son produit. Nous y consacrons un article entier dans la suite de cette série.

Le bus factor ensuite : la mesure du nombre de personnes dont la disparition bloquerait le projet. Un code brillant détenu par un seul cerveau vaut moins qu’un code moyen détenu par une équipe, parce que le premier peut partir. C’est le risque n°1 que les investisseurs sous-estiment, et il mérite l’examen dédié que nous lui consacrons dans cette même série.

La dette technique enfin, à condition de la lire correctement : la question n’est pas « y a-t-il de la dette ? » (il y en a toujours, et une startup sans aucun raccourci a probablement construit trop lentement), mais « l’équipe sait-elle où elle est, et la rembourse-t-elle ? ». La grille de mesure est dans notre article sur la dette technique.

Comment se déroule concrètement l’audit ?

En quatre temps, sur 3 à 10 jours pour une startup early stage. La lecture d’architecture d’abord : structure du code, choix techniques, documentation, pour comprendre l’objet avant de le juger. Les sondages ensuite : plutôt que tout lire, l’auditeur choisit trois ou quatre parcours critiques (l’inscription, le paiement, le cœur métier) et les suit dans le code de bout en bout ; la qualité de ces tranches prédit fiablement le reste. La revue d’infrastructure et d’accès en parallèle : qui peut toucher la production, comment on déploie, ce qui se passerait en cas d’incident. Les entretiens enfin, souvent les plus révélateurs : demander à chaque développeur « qu’est-ce qui te fait peur dans ce code ? » produit une carte des risques qu’aucun outil d’analyse ne donne.

Un point d’honnêteté sur les scores : quand un rapport annonce une note sans les constats qui la justifient, il ne vaut rien. Chaque point de la grille doit être adossé à des exemples précis tirés du code, avec l’impact et le coût de correction estimé. C’est le même principe qui structure notre méthode sur tout projet : mesurer avant d’affirmer.

Quelles sont les découvertes les plus fréquentes ?

Cinq constats reviennent si régulièrement qu’ils méritent d’être attendus, avec leur gravité réelle plutôt que celle qu’on leur prête :

1. Les accès de production partagés. Un compte administrateur commun, un mot de passe qui circule, d’anciens prestataires jamais révoqués. Grave en apparence, réparable en quelques jours : c’est un chantier d’hygiène, pas un vice de structure.
2. L’absence de tests sur les parcours critiques. Presque universelle en early stage, et rationnelle tant que le produit cherchait encore sa forme. Elle devient un risque au moment précis où le rythme des évolutions doit s’accélérer avec l’argent levé : elle se budgète dans le plan post-investissement.
3. Le freelance fantôme dans la chaîne des droits. Un contributeur passé, parti sans cession écrite. Invisible dans le code, décisif dans la transaction : c’est le constat qui transforme le plus souvent un audit de routine en négociation juridique.
4. La dépendance non documentée à une personne. Le bus factor de 1, rarement avoué, jamais écrit, toujours découvert en entretien. C’est le constat le plus structurel des cinq, et le seul qui ne se corrige pas avec un chèque.
5. L’écart entre le pitch et le code. « Notre IA propriétaire » qui s’avère un appel d’API, « notre plateforme scalable » qui tient sur un serveur unique. Ce n’est pas toujours disqualifiant, le produit peut être excellent ainsi, mais l’écart de discours, lui, dit quelque chose de la relation qui s’annonce.

Aucune de ces découvertes ne devrait surprendre un fondateur préparé : ce sont exactement les points que la grille ci-dessus permet de mettre en ordre avant que quelqu’un d’autre ne les découvre à votre place.

Combien coûte une due diligence technique, et qui la paie ?

Quelques jours d’expertise senior : sur la base des taux du marché, un audit de 3 à 10 jours représente un budget de l’ordre de 3 000 à 10 000 € HT selon la taille du code et la profondeur demandée. Rapporté aux montants en jeu, un tour de table se mesure en centaines de milliers d’euros, une acquisition en millions, c’est l’assurance la moins chère de toute la transaction.

L’usage veut que celui qui décide paie : l’investisseur ou l’acquéreur commande l’audit qui éclaire sa décision. Mais le mouvement le plus rentable est souvent inverse : le fondateur qui commande son propre audit trois mois avant la levée transforme chaque constat en chantier réglé plutôt qu’en argument de négociation adverse. Arriver en due diligence avec le rapport déjà fait, les corrections déjà menées et les preuves en face de chaque axe change la dynamique de la discussion : vous n’êtes plus audité, vous présentez.

Que faire des résultats, côté investisseur et côté fondateur ?

Côté investisseur, la grille de lecture tient en trois catégories. Les défauts réparables (dette localisée, tests manquants, documentation en retard) se chiffrent et s’intègrent au plan post-investissement : ils peuvent justifier un ajustement, jamais un retrait. Les risques structurels (bus factor de 1, déploiements artisanaux) se négocient en conditions : recrutement, documentation ou accompagnement à financer sur les fonds levés. Les vices bloquants (propriété du code incertaine, faille exploitée, dépendance juridique non résolue) se traitent avant la signature ou pas du tout.

Côté fondateur, le geste concret s’appelle la data room technique : un dossier prêt avant même la première discussion, avec un accès en lecture au dépôt de code, la documentation d’architecture, le registre des contributeurs et de leurs cessions, l’inventaire des accès et, idéalement, un rapport d’audit indépendant de moins de six mois. Le préparer prend quelques jours ; le sortir en vingt-quatre heures quand un fonds le demande envoie un signal que peu de dossiers envoient. Le meilleur conseil tient en un mot : anticipez. Le cas classique que ce scénario recouvre : une startup en discussion avancée avec un fonds, dont l’audit révèle que le cœur du produit a été développé dix-huit mois plus tôt par un freelance parti sans signer de cession. Rien d’irrattrapable, mais trois semaines de négociation juridique en pleine levée, un rapport de force dégradé, et une leçon coûteuse : chaque point de la grille ci-dessus se met en ordre pour quelques jours de travail quand on s’y prend avant, et se paie en points de valorisation quand on le découvre pendant.

C’est aussi, en creux, la meilleure façon d’évaluer un futur partenaire technique : demandez-lui comment son travail traverserait cette grille. Un studio sérieux doit pouvoir répondre point par point, preuves à l’appui : c’est notre cas sur chacun de ces axes, du dépôt au nom du client dès le premier jour aux déploiements automatisés, et c’est vérifiable sur nos produits en production comme sur les projets que nous menons en dev for equity, où nous sommes des deux côtés de la table à la fois.

Si vous préparez une levée, une acquisition ou un investissement et que la partie technique du dossier reste une zone grise, parlons-en : quelques jours d’audit remplacent l’incertitude par une carte, et une carte se négocie toujours mieux qu’un brouillard.