Accueil/Ressources/Checklist

Note

Checklist de due diligence technique

Les questions que je trouve pertinent de poser, et ce que j'écoute dans la réponse.

Mis à jour le 1er septembre 2026

Ceci n'est pas un questionnaire à faire remplir. Envoyé tel quel, il revient avec vingt réponses écrites, polies, et sans grande valeur. Ces questions se posent en entretien, où l'information est rarement dans le contenu de la réponse : elle est dans le temps qu'il faut pour y arriver, dans la précision des exemples, et parfois dans le regard que deux ingénieurs échangent quand la question tombe.

Les meilleures questions sont celles dont la cible connaît la réponse. Ce que je mesure, c'est la vitesse à laquelle elle arrive.

Chaque point ci-dessous est formulé comme je le pose, suivi de ce que j'en tire. Les quatre sections reprennent mes axes d'audit : architecture, code, sécurité, équipe.

I. Architecture & scalabilité

• Quel volume traitez-vous aujourd'hui, et quel volume prévoit le business plan dans trois ans ? Le rapport entre les deux commande tout le reste de l'entretien. Un facteur deux ne pose presque jamais de problème. Un facteur cinquante en pose toujours un, même dans une architecture soignée.
• Si le trafic est multiplié par dix demain matin, qu'est-ce qui lâche en premier ? Une équipe qui a fait l'exercice répond en quelques secondes et nomme un composant précis, souvent la base de données. Celle qui répond « on scalera horizontalement » ne l'a jamais fait.
• Combien vous coûte un client en infrastructure, et comment ce coût évolue-t-il ? C'est le point que les acquéreurs manquent le plus souvent. Une facture qui croît plus vite que le chiffre d'affaires est un problème de modèle économique déguisé en problème technique.
• Quelle décision d'architecture serait impossible à défaire aujourd'hui ? Toute architecture en compte. Le risque n'est pas qu'elles existent : c'est que personne dans l'équipe ne sache lesquelles.
• Que se passe-t-il si vous perdez votre hébergeur principal ? Je ne cherche pas à imposer du multi-cloud, qui se justifie rarement. Je veux savoir si la dépendance est mesurée ou subie.

II. Code & dette technique

• Quelle partie du code personne n'ose plus toucher ? Il y en a toujours une. Une équipe en confiance la nomme tout de suite, sans gêne, parfois avec humour. Une équipe qui affirme qu'il n'y en a pas ne connaît pas son système ... ou ne me dit pas tout.
• Combien de temps entre un commit et sa mise en production ? Indicateur classique mais bigrement efficace. Il agrège la qualité des tests, l'automatisation, le découpage du code et la confiance de l'équipe dans son propre travail.
• Quelle est votre dépendance la plus critique, et quand l'avez-vous mise à jour ? Une bibliothèque abandonnée au cœur d'un système de paiement est un risque que je sais chiffrer. Trois cents dépendances mineures en retard, non.
• Que couvrent réellement vos tests ? Le taux de couverture ne m'intéresse pas. La question utile est : quand un test échoue, est-ce que l'équipe le croit ? Une suite qu'on relance jusqu'à ce qu'elle passe ne protège plus de rien.
• Combien de temps met un nouvel ingénieur avant sa première mise en production ? Deux jours ou quatre semaines : ce ne sont pas les mêmes entreprises, quelle que soit la qualité apparente du code.

III. Sécurité & conformité

• Qui peut lire les données de production, et comment le savez-vous ? La deuxième moitié de la question est la vraie. Une liste d'accès qu'on ne peut pas produire en séance est une liste que personne ne revoit.
• Quel a été votre dernier incident de sécurité ? Une entreprise qui n'en a jamais eu ne les détecte pas. Répondre franchement à cette question est en général bon signe ; le silence gêné l'est beaucoup moins. Et montrer quelque chose et généralement très bon signe pour toutes les étapes nécessaire à l'incident mangement.
• Comment un secret arrive-t-il en production ? Le chemin que suit une clé d'API en dit plus long sur la maturité réelle que n'importe quelle politique de sécurité écrite.
• Quelles données personnelles conservez-vous, où, et combien de temps ? L'incapacité à répondre est fréquente, et coûteuse : elle signale une conformité documentaire plutôt qu'opérationnelle.
• Vos certifications couvrent-elles le périmètre que j'achète ? Une certification ISO 27001 peut porter sur un périmètre très étroit. Je lis la déclaration d'applicabilité, pas le certificat encadré dans le hall.

IV. Équipe & organisation

• Si cette personne part demain, que perdez-vous ? Je pose la question séparément à trois interlocuteurs. Trois fois le même nom : la dépendance est établie. Trois noms différents : l'organisation est plus solide qu'elle n'en avait l'air.
• Qui a écrit la partie la plus critique, et travaille-t-il encore ici ? L'historique du dépôt me répond avant l'équipe. C'est l'écart entre les deux réponses qui m'intéresse.
• Comment décidez-vous de ce que vous construisez ? Une roadmap technique qui n'existe que dans la tête du fondateur reste un risque de personne clé, même à vingt ingénieurs.
• Combien de départs sur les trois dernières années ? À croiser avec les dates du dépôt. Les départs se voient dans l'historique bien avant d'être évoqués en entretien.
• Que feriez-vous avec six mois sans nouvelle fonctionnalité ? La réponse dessine la carte de la dette telle que l'équipe la vit. C'est souvent le meilleur inventaire disponible, et il ne coûte rien.

V. Ce que cette liste ne remplace pas

Une checklist protège de l'oubli, pas de l'erreur de jugement. Elle ne dit pas quelle réponse est grave dans votre dossier : une architecture fragile pèse peu si vous rachetez une équipe, et beaucoup si vous rachetez une plateforme. Ce tri suppose de connaître la thèse d'investissement, et c'est pour cette raison que le cadrage passe toujours avant les questions.

Elle ne remplace pas non plus la lecture du code et de l'historique du dépôt. Les entretiens donnent la version que l'entreprise a d'elle-même. Elle est précieuse, mais elle se vérifie.

← Toutes les ressources