Fonds : faire auditer par des ingénieurs qui construisent

Un audit technique pour un fonds d’investissement peut être conduit par deux profils : des analystes qui appliquent une grille, ou des ingénieurs qui construisent le même type de systèmes que la cible. Sur du logiciel classique, la différence est réelle mais gérable. Sur une cible IA, elle change la conclusion, parce que les risques propres à l’IA ne figurent dans aucune grille générique.

Nous faisons les deux métiers : nous mettons des systèmes IA en production pour des clients, et nous auditons des cibles pour des fonds. Ce que la pratique de construction apporte à l’audit tient en quatre observations concrètes.

Ce qu’une grille générique évalue bien

Commençons par ce qui fonctionne. La grille classique couvre correctement l’architecture, la sécurité, la qualité du code, la scalabilité et l’organisation de l’équipe. Un auditeur généraliste expérimenté y détecte l’essentiel : les secrets dans le code, l’absence de tests, les dépendances risquées, la concentration du savoir. Pour un SaaS sans composante IA, cela couvre la plus grande partie du sujet.

Le problème est que les cibles IA échouent ailleurs. Leurs risques spécifiques, une qualité de réponse qui se dégrade sans alerte, des marges suspendues aux tarifs d’un fournisseur, une défensibilité déclarée mais introuvable, ne laissent pas de trace dans une revue d’architecture. Il faut savoir où regarder, et on ne sait où regarder que si l’on a déjà construit.

La pratique d’évaluation, premier révélateur

La question qui sépare le plus vite les équipes IA sérieuses des autres : comment savez-vous que votre système répond bien ? Une équipe mature montre un jeu d’évaluation versionné, des mesures avant chaque mise en production, un suivi de la qualité en continu. Une équipe fragile répond "nous testons à la main, et les retours clients sont bons".

Un auditeur qui n’a jamais construit de jeu d’évaluation cochera "processus de QA : oui" dans les deux cas. Celui qui en construit régulièrement sait quelles questions poser ensuite : combien d’exemples, comment le jeu évolue, que s’est-il passé au dernier changement de modèle. La différence entre les deux réponses vaut parfois plusieurs points de multiple, parce qu’elle prédit la capacité de l’équipe à faire évoluer le produit sans le casser.

Les boucles de données et la fausse défensibilité

"Notre produit s’améliore avec l’usage" figure dans la plupart des decks IA. C’est parfois vrai. Le vérifier demande de suivre le chemin complet : quelles données sont réellement collectées, où elles sont stockées, et surtout quel mécanisme les réinjecte dans le produit. Dans une bonne partie des dossiers que nous voyons, la boucle s’arrête au stockage : les données s’accumulent, rien n’apprend. Collecter n’est pas apprendre.

Ce regard tranche aussi la question de la surcouche : distinguer une vraie profondeur produit, workflow intégré, données propriétaires exploitées, coûts maîtrisés, d’une interface soignée posée sur une API se fait en lisant le code et les flux de données, pas en écoutant le pitch. Un ingénieur qui a construit les deux reconnaît chacun en quelques heures.

Les marges sous les démos

Une cible IA peut montrer une croissance superbe et perdre de l’argent sur chaque requête. La sensibilité de la marge aux prix des modèles, la distribution de consommation entre utilisateurs, le coût complet d’une action : cette lecture de l’économie unitaire suppose d’avoir soi-même payé des factures d’inférence et arbitré entre modèles. C’est un réflexe d’opérateur, pas une ligne de grille.

Ce que cela change dans le rapport

La différence se voit dans les livrables. Un rapport d’ingénieurs chiffre les trouvailles en euros et en mois plutôt qu’en adjectifs de sévérité : "la refonte du pipeline occupera deux ingénieurs pendant un trimestre" engage plus que "dette technique significative". Il relie chaque risque au plan de création de valeur, ce qui bloque la roadmap financée et ce qui peut attendre. Et il débouche sur un plan d’action que l’équipe de la cible peut réellement exécuter, parce qu’il a été écrit par des gens qui exécutent ce genre de plan.

C’est enfin une question de dialogue avec la cible. Les CTO parlent différemment à des auditeurs capables de lire leur code et de comprendre leurs arbitrages. Les questions posées aux fondateurs obtiennent de meilleures réponses quand celui qui les pose sait entendre la différence entre une réponse solide et une réponse préparée.

C’est le principe sur lequel repose notre offre d’audit technique et IA : les mêmes ingénieurs qui mettent des systèmes en production pour nos clients auditent les cibles de nos fonds. Non par goût du cumul, mais parce que sur l’IA, on n’évalue bien que ce qu’on sait construire.