Chez Batch, on vient d’acquérir la technologie Moonfish. Pour instruire cette acquisition, on a conduit la due diligence tech en interne, sans cabinet de conseil externe. Avec Claude à chaque étape.
Le bilan en 3 points :
2 semaines de travail consultant économisées ;
Entre 30 et 50k€ économisés par rapport à ce que facturerait un cabinet d’audit tech spécialisé ;
Des échanges bien plus fluides qu’on ne l’anticipait avec l’équipe Moonfish.
Notre méthode expliquée dans cet article.
La due diligence tech : un exercice structurellement difficile
Une due diligence technologique, c’est l’évaluation approfondie d’une technologie avant une acquisition. On y examine la qualité du code, les patterns d’architecture, les pratiques de développement, la dette technique, les pratiques de sécurité. Le tout en temps contraint, avec des équipes qui ne se connaissent pas encore.
Historiquement, deux options s’offrent aux acheteurs.
La première : faire confiance aux ateliers techniques pour faire remonter l’essentiel. C’est rapide mais lacunaire. Sans cadre d’évaluation commun, les retours restent subjectifs et difficiles à consolider.
La deuxième : faire appel à un cabinet d’audit tech spécialisé. Plus fiable, mais une mission de ce type se facture entre 30 et 50k€ pour un périmètre comparable au nôtre, avec des délais qui dépassent souvent les 2 semaines.
On n’avait ni le temps d’attendre un cabinet, ni envie de conduire des ateliers à l’aveugle. On a construit autre chose.
Étape 1 : préparer les ateliers avec Claude
La préparation des ateliers d’une due diligence est un travail fastidieux : identifier les thèmes à couvrir, formuler les bonnes questions, créer des outils d’évaluation exploitables. En temps normal, comptez plusieurs jours pour un consultant expérimenté.
On a soumis à Claude les objectifs macro de chaque atelier. En retour, il a :
Organisé les ateliers dans un ordre logique ;
Complété notre base de questions pour chaque session ;
Produit des scorecards (fiches d’évaluation) intégrables dans Notion, prêtes à être remplies par les participants côté Batch à l’issue de chaque atelier ;
Généré la documentation associée pour expliquer aux évaluateurs comment remplir chaque fiche.
Bon à savoir : partager le cadre d’évaluation à l’avance avec l’équipe Moonfish a eu un effet inattendu. Les ateliers sont devenus plus fluides, parce que tout le monde savait exactement ce qu’on cherchait à évaluer. Moins de défensivité, plus de franchise.
Une fois les fiches d’évaluation remplies par les équipes Batch, Claude a consolidé l’ensemble des évaluations en un rapport de synthèse le jour même. Ce qui prend habituellement une journée complète de rédaction.
Bilan de cette première phase :
Organisation et préparation : plusieurs jours réduits à quelques heures ;
Qualité et homogénéité des retours améliorées grâce aux fiches structurées ;
Consolidation post-ateliers disponible le jour même.
Étape 2 : analyser le code sans outillage dédié
L’analyse de code, c’est le point où les due diligences internes déraillent. Sans outil spécialisé, comment lire objectivement une base de code qu’on ne connaît pas ?
Se fier aux seuls ateliers, c’est prendre le risque de passer à côté de ce que les développeurs n’auraient pas soulevé d’eux-mêmes. Et déployer un outil d’audit externe chez la cible ouvre des discussions sur les accès, la confidentialité, l’installation. Tout ça prend du temps et crée de la friction.
On a proposé à Moonfish quelque chose de plus simple : un prompt et une clé API Claude fournis par Batch. Les équipes de Moonfish l’ont exécuté elles-mêmes, sur leurs propres espaces de stockage, depuis leur propre environnement.
Ce choix avait trois avantages immédiats :
Zéro installation : pas d’outillage complexe à déployer, pas de négociation d’accès ;
Transparence totale : le prompt était lisible par les équipes Moonfish avant exécution. Pas de boîte noire ;
Une ressource partagée : le résultat de l’analyse est devenu une base commune entre Batch et Moonfish, pas un rapport unilatéral de l’acheteur.
L’atelier de revue de base de code qui a suivi était d’une efficacité rare. On a parcouru les analyses dépôt par dépôt. Claude avait remonté des observations concrètes sur les pratiques de développement, les patterns d’architecture et les pratiques de sécurité dans le code. Pas de débats abstraits. Pas de défensivité. Juste des conversations basées sur un constat factuel partagé.
Ce que ça change pour une due diligence tech
Cette expérience illustre un changement plus profond dans la façon dont les équipes tech peuvent conduire des processus d’acquisition.
Les LLM (grands modèles de langage) changent l’équation sur 3 points :
La structuration. Produire un cadre d’évaluation rigoureux (questions, fiches d’évaluation, documentation associée) était une compétence rare. C’est désormais accessible en quelques heures, à condition de savoir formuler les bons objectifs.
L’analyse. L’audit de code était réservé aux experts ou aux outils coûteux. Un prompt bien construit, exécuté sur une base de code, produit une lecture utile des pratiques et des risques. Ce n’est pas un audit certifié. C’est un point de départ de discussion, factuel et partagé.
La synthèse. La consolidation des retours d’ateliers est une tâche longue à faible valeur ajoutée. C’est exactement le type de tâche qu’un LLM traite bien : agréger, structurer, résumer, sans perdre les nuances.
⚠️ Attention : cette approche ne remplace pas le jugement humain à l’étape finale. L’analyse d’un LLM sur une base de code est un outil de conversation, pas un verdict. Ce sont les ingénieurs qui interprètent les remontées et posent les questions qui comptent.
Hervé Lourdin
Chief Technical Officer @ Batch
Rejoignez-nous
La Newsletter du CRM
Toutes les nouveautés dans votre boîte mail !
