Comment se préparer à une Due Diligence technique

Si vous travaillez dans une startup, il est possible que tôt ou tard vous deviez passer par une due diligence. Que ce soit parce qu’une autre entreprise veut vous acheter ou investir en vous, ou parce qu’un grand client souhaite contracter vos services ou produits. Personnellement, j’ai vécu les due diligence des deux côtés, d’abord en tant que CTO lorsque des investisseurs voulaient investir, puis en tant que fractional CTO jouant le rôle d’auditeur pour certains clients.

La due diligence est un processus d’audit auquel une entreprise se soumet pour mieux comprendre sa valeur réelle. Normalement, différents aspects sont examinés, tels que les aspects technique, fonctionnel, financier ou juridique. L’objectif est de collecter le maximum d’informations possible sur le fonctionnement interne de la startup, afin de valider l’hypothèse d’investissement ou d’acquisition et de détecter d’éventuels risques et problèmes qui ne sont pas évidents de l’extérieur. Pour cela, une analyse approfondie est réalisée, où l’on entre littéralement dans la cuisine, on parle avec les cuisiniers, on goûte la nourriture, on examine comment elle est préparée, on cherche des problèmes de qualité dans la nourriture, et on peut même aller jusqu’à parler avec les clients.

Dans ce post, je me concentrerai sur les due diligence techniques, qui évaluent les produits et actifs technologiques développés par la startup, ainsi que les équipes d’ingénierie, leurs méthodologies de travail, et tous les aspects techniques nécessaires au maintien de l’activité, comme la sécurité, la conformité, etc.

Quels aspects sont examinés dans les due diligence techniques

Normalement, les aspects suivants sont examinés :

Actifs technologiques. On cherche à comprendre comment les produits de la startup sont développés, le stack technologique utilisé, l’architecture technique, l’infrastructure et le code source. L’objectif est de répondre à des questions du type : le stack technologique est-il actuel et adapté ? Combien coûtera l’évolution et la maintenance du produit ? L’infrastructure offre-t-elle une résilience suffisante pour maintenir le service en fonctionnement même en cas de pannes ? Le niveau de dette technique est-il raisonnablement bas ?
Sécurité. Comment le système et ses données sont-ils protégés ? Existe-t-il de bonnes pratiques qui minimisent le risque d’introduire des vulnérabilités ? Y a-t-il des profils ou des équipes dédiés à la sécurité ? Une surveillance active de la sécurité est-elle en place ?
Équipe. Les leaders techniques sont-ils compétents ? Le dimensionnement des équipes est-il adéquat ? Existe-t-il des profils QA ? Y a-t-il des devops ? Y a-t-il des Product Managers ? Le turnover est-il faible ?
Processus. Quelle méthodologie de travail suivent les équipes d’ingénierie ? Existe-t-il une culture d’amélioration continue ? Comment le backlog produit est-il défini ? Y a-t-il des principes bien définis qui guident le travail ? Existe-t-il des processus adaptés pour supporter et maintenir le service ?
Conformité. La startup a-t-elle des procédures pour se conformer au RGPD ? Dispose-t-elle de certifications ISO (ISO 27001, ISO 9001, ISO 22301, … ) ?
Fournisseurs de technologie. Des services de fournisseurs externes ont-ils été contractés ? Quelles parties sont externalisées ? Y a-t-il des parties core externalisées ?

Problèmes et schémas qui se répètent dans les due diligence

Il est courant qu’en réalisant une due diligence en tant qu’auditeur, on observe de manière répétée une série de schémas et de problèmes. D’après mon expérience, voici certains des plus importants :

Manque de culture agile et d’une mise en oeuvre robuste. De manière assez généralisée, j’ai observé une adoption et une mise en pratique assez déficiente des méthodologies agiles. Scrum semble être le roi des frameworks agiles dans les startups qui développent des produits logiciels. Dans l’immense majorité, les cérémonies stipulées sont suivies, mais il n’y a pas de compréhension réelle des principes ni de la philosophie agile, ce qui fait qu’on continue à utiliser une mentalité obsolète sous l’étiquette de l’agilité. Un schéma que j’ai rencontré de manière récurrente est la réalisation de rétrospectives périodiques mais sans impact réel, sans amélioration continue. Au-delà de la méthodologie, examiner comment ils travaillent avec Scrum donne beaucoup d’informations sur la culture.
L’adoption du QA Automation et du DevOps est plus basse qu’il n’y paraît. Bien que cela fasse plus d’une décennie que leur adoption a commencé, il est surprenant de voir combien d’entreprises ne les utilisent pas ou ont des implémentations très partielles, dépendant trop du testing et des déploiements manuels.
Le standard de qualité est trop bas. Souvent, un nombre élevé d’incidents en production est accepté comme raisonnable. L’une des choses que j’observe le plus lors d’une due diligence est le nombre de bugs et d’incidents en production au cours de la dernière année. Et j’ai été surpris de constater que ce nombre n’est généralement pas bas.
La sécurité est souvent traitée comme un aspect secondaire que l’on repousse jusqu’à ce qu’il soit inévitable, principalement par manque de temps et parce qu’elle n’est pas perçue comme une priorité pour le business. Dans certains cas extrêmes, j’ai rencontré de mauvaises pratiques, comme des mots de passe et des clés API en texte clair dans les dépôts de code. Une faille de ce type a exposé un nombre important de dépôts de Mercedes Benz il y a quelques mois, par exemple.
Il y a peu de product management, beaucoup de startups n’ont pas de roadmaps bien définies ni de profils de product management. Il est assez courant que les demandes d’un client finissent par se traduire en fonctionnalités, avec peu d’analyse quant à leur adéquation avec la stratégie produit.

Comment se préparer ?

Voici quelques éléments qui me semblent importants pour se préparer à une Due Diligence technique :

Comprendre l’accord qui est envisagé. Cet aspect est clé car il déterminera comment le ou les auditeurs mèneront la due diligence, et ce qu’ils vont examiner. Savoir si on envisage l’acquisition de l’entreprise ou un investissement, et quelles sont les intentions en cas de réalisation, c’est-à-dire si on veut intégrer la startup dans l’entreprise acquéreuse ou si, au contraire, on veut la maintenir comme une entreprise indépendante. Si l’intégration de la startup est envisagée, des aspects comme le stack technologique, l’équipe et la culture prennent une importance accrue.
Répondre avec qualité et exhaustivité. Presque toutes les due diligence sont accompagnées de questionnaires dans lesquels on demande de répondre à plusieurs questions qui peuvent porter sur des sujets comme la technologie, la sécurité, les personnes, les processus, la conformité ou les fournisseurs. Il est fréquent que les ingénieurs chargés de répondre à ces questionnaires soient des personnes très occupées et qu’ils les perçoivent comme une formalité fastidieuse qui leur retire du focus sur leurs tâches quotidiennes. De plus, on ne réserve généralement pas beaucoup de temps pour ce type de travaux, ce qui fait que souvent les réponses sont données rapidement, sans qualité suffisante et avec des informations incomplètes. Le problème est que d’un côté nous montrons peu d’attention à la qualité face aux auditeurs et de l’autre nous compliquons leur travail, ce qui aura probablement un impact négatif. Il est vrai que beaucoup d’auditeurs sont conscients des raisons qui poussent les ingénieurs à répondre aux questionnaires de cette manière, mais l’auditeur ne peut pas deviner ce qui n’est pas dit ou est présenté de manière incomplète. Et avec tout cela, nous risquons d’avoir une évaluation défavorable et peu fidèle à la réalité, avec ce que cela implique pour la stratégie et l’avenir de la startup.
Éviter de donner une image irréaliste. L’auditeur ou les auditeurs qui réalisent la Due Diligence ont probablement suffisamment d’expérience pour savoir que dans toutes les entreprises, il y a des imperfections. Et ils savent aussi que parfois les startups tentent de vendre une idée de leur valeur qui est éloignée de la réalité. L’une des choses qui me fait le plus suspecter, en tant qu’auditeur, c’est une startup qui semble cocher toutes les cases techniques (ex : elle utilise les meilleures pratiques, n’a pratiquement pas d’incidents en production, utilise des méthodologies agiles qui s’améliorent continuellement grâce à des métriques, n’a pas de turnover, et dispose d’une excellente sécurité… et tout cela est accompli avec une équipe de 5 ingénieurs). Mais répondre aux questionnaires en essayant de projeter une image trop parfaite ne tient généralement pas longtemps. Car les questionnaires sont habituellement accompagnés de réunions, où des preuves sont demandées pour valider les réponses, ainsi que de l’accès aux outils et aux dépôts de code pour les inspecter. Et si un auditeur détecte qu’on a tenté de le tromper, cela peut être un drapeau rouge. Personnellement, je valorise davantage les équipes qui sont sincères dans leurs réponses et reconnaissent quand elles ne satisfont pas à un certain critère. Et si en plus elles donnent des preuves d’avoir déjà identifié ce point et d’avoir planifié une action d’amélioration, c’est un grand plus.
Impliquer les meilleurs ingénieurs. Comme nous l’avons mentionné plus haut, donner une bonne réponse aux questionnaires de la due diligence est clé, et sans aucun doute la meilleure façon de le faire est d’impliquer les ingénieurs qui connaissent le mieux la technologie. De plus, lorsqu’on évalue l’achat ou l’investissement dans une startup, l’un des aspects primordiaux concerne l’équipe et le talent dont elle dispose. Il est presque certain que l’auditeur voudra connaître l’équipe de première main, et surtout les leaders techniques. Ils ne le demanderont peut-être pas explicitement, il est donc bon d’être proactif en impliquant les meilleurs pour obtenir une bonne évaluation sur l’aspect équipe. Une réunion dans laquelle les ingénieurs de la startup démontrent leur séniorité et leur maîtrise des sujets traités et de leurs domaines peut être un facteur différenciant… Tout comme dans les entretiens d’embauche.

Conclusions

Si la startup dans laquelle vous travaillez se porte bien, il est très probable que tôt ou tard vous serez confronté à une due diligence, et être capable de donner une bonne réponse à la partie technique est clé. Comme en toute chose, la préparation est cruciale, lui donner la priorité qu’elle mérite, impliquer les meilleurs ingénieurs et ne pas essayer de donner une image irréaliste vous aidera. Mais sans aucun doute, la meilleure façon de se préparer à une due diligence technique est de commencer avant même qu’elle ne se présente comme une option lointaine. Car ce qui est évalué, c’est l’état actuel de la startup et de ses actifs, qui sont le fruit d’un travail prolongé. Lors de la due diligence, peuvent être mis au jour une culture déficiente, de mauvaises pratiques de programmation, des défauts de conception, des vulnérabilités, des failles de sécurité, des violations du RGPD, … Et tout cela peut impacter le deal.