OpenAI vient de recruter le créateur du projet open source le plus critiqué par la communauté cybersécurité en 2026. Dix CVE critiques, 824 extensions vérolées, 135 000 instances exposées sur Internet. Et pourtant, Sam Altman a signé. Qu'est-ce que ça raconte sur l'état de la due diligence technique aujourd'hui ?
Il y a encore six mois, lors de ma dernière due diligence technique sur une opération de fusion-acquisition, les choses étaient assez balisées. On regardait la qualité du code, la couverture de tests, l'architecture, la dette technique, la dépendance aux personnes clés. On posait les bonnes questions au CTO, on auditait le repo, on cochait des cases. C'était un exercice rigoureux mais prévisible.
Et puis le vibe coding est arrivé.
Le vibe coding, c'est cette façon de construire des applications en dialoguant avec des IA. Tu décris ce que tu veux, Cursor ou Claude Code génère le code, tu itères. Un développeur seul peut sortir en un week-end ce qui prenait trois mois à une équipe de cinq. C'est l'imprimerie appliquée au code : tout le monde peut désormais créer.
Le problème, c'est que tout le monde peut aussi créer n'importe quoi. Et que ce n'importe quoi peut valoir des centaines de millions.
Le cas d'école : OpenClaw
Mi-février 2026, OpenAI annonce le recrutement de Peter Steinberger, développeur autrichien et créateur d'OpenClaw, un assistant personnel IA open source. Le projet, lancé en novembre 2025 sous le nom ClawdBot (renommé MoltBot après un rappel à l'ordre d'Anthropic sur la marque Claude, puis OpenClaw), avait explosé tous les compteurs : 200 000 étoiles GitHub, 41 800 forks, une croissance jamais vue dans l'histoire de la plateforme.
Sam Altman salue un « génie » sur X. Le projet intégrera une fondation open source soutenue par OpenAI. Steinberger pilotera « la prochaine génération d'agents personnels ». Meta et Microsoft avaient aussi fait des offres. Satya Nadella avait appelé en personne.
Sauf que.
Au moment de cette opération, le bilan sécurité d'OpenClaw ressemblait à un rapport d'incident, pas à un produit prêt pour la production.
Les chiffres qui piquent
Commençons par les CVE, ces vulnérabilités référencées publiquement. OpenClaw en cumulait dix au moment de l'acquisition, assorties de quatorze GitHub Security Advisories, dont cinq corrigées dans la même semaine fin janvier 2026. Parmi elles, la CVE-2026-25253 : une faille permettant l'exécution de code à distance en un seul clic, notée 8.8 sur 10 en criticité. Il suffisait de visiter une page web piégée pour que l'attaquant prenne le contrôle total de l'agent, même sur une instance configurée en local. Le navigateur de la victime faisait le travail tout seul.
Dans la foulée, deux autres failles critiques : une injection de commandes SSH via un chemin de projet malveillant sur macOS (CVE-2026-25157), et un contournement de la sandbox Docker par manipulation du PATH (CVE-2026-24763). Toutes avec des exploits publics, c'est-à-dire que n'importe qui pouvait les utiliser.
Côté marketplace, le constat était encore plus sombre. ClawHub, le dépôt d'extensions communautaires, comptait 824 skills malveillantes identifiées par les chercheurs. Une étude Snyk a montré que 36 pourcent de l'ensemble des skills du catalogue contenaient des failles de sécurité. La campagne la plus massive, baptisée ClawHavoc, avait distribué un infostealer ciblant les portefeuilles crypto, les clés SSH et les mots de passe des navigateurs sur macOS.
Les chiffres d'exposition réseau complétaient le tableau. SecurityScorecard et Bitsight ont identifié plus de 135 000 instances OpenClaw exposées sur Internet dans 82 pays, dont près de 13 000 directement exploitables via exécution de code à distance. L'image Docker officielle du projet embarquait à elle seule 2 062 vulnérabilités connues.
Et la cerise : les tokens API, les clés d'authentification et les données de session étaient stockés en clair dans des fichiers Markdown et JSON. La base Supabase de Moltbook, le réseau social satellite, avait exposé 1,5 million de tokens API et 35 000 adresses email.
Cisco Talos a qualifié le projet de « cauchemar sécuritaire ». The Register l'a traité de « dumpster fire ». Meta l'a banni de ses appareils professionnels. Palo Alto Networks, CrowdStrike, Bitdefender et Kaspersky ont tous publié des avis de sécurité dédiés.
Quand un journaliste a interrogé Steinberger sur ces problèmes, il a répondu que la sécurité « n'était pas vraiment quelque chose qu'il souhaitait prioriser ». Le projet n'avait ni programme de bug bounty, ni budget sécurité.
Alors pourquoi OpenAI a signé ?
C'est la question qui devrait hanter tous les professionnels du M&A tech. Et la réponse est inconfortable : parce que la grille d'évaluation classique ne capture plus ce qui a de la valeur en 2026.
Ce qu'OpenAI a acheté, ce n'est pas du code. Le code d'OpenClaw est un chantier. Ce qu'ils ont acheté, c'est un créateur qui a prouvé qu'un développeur seul, avec les bons outils IA, pouvait construire le projet open source à la croissance la plus rapide de l'histoire et fédérer une communauté mondiale en quelques semaines.
Steinberger incarne exactement le profil que le vibe coding rend possible : un créatif avec une vision produit, une capacité d'exécution fulgurante, et une compréhension intuitive de ce que les gens veulent. Qu'il ne maîtrise pas la sécurité de ce qu'il construit, OpenAI s'en chargera. Ils ont les équipes, les moyens, l'infrastructure.
C'est rationnel du point de vue de l'acquéreur. Mais c'est un signal d'alerte pour notre métier.
Ce que ça change pour la due diligence
Quand un acquéreur peut regarder un projet criblé de failles, le valoriser à un montant non divulgué mais estimé à plusieurs dizaines de millions, et considérer que c'est un bon deal, ça veut dire que nos critères d'évaluation ont un train de retard.
Le code n'est plus l'actif principal. Le talent, la traction et la communauté pèsent désormais plus que la propreté technique. C'est un changement de paradigme qu'on peut accepter ou refuser, mais qu'on ne peut pas ignorer.
Pour autant, ça ne dispense pas de faire le travail. Ça oblige à le faire différemment.
Quand j'évalue un projet en 2026, les questions que je pose au CTO ne sont plus les mêmes qu'il y a deux ans. Aujourd'hui, je veux voir le workflow de développement en live. Pas une architecture théorique, pas un PowerPoint. Je veux savoir quels IDE et CLI l'équipe utilise au quotidien. Est-ce qu'ils travaillent avec plusieurs LLM en cross-check, ou est-ce qu'ils copient-collent la première sortie de Cursor sans relire ? Est-ce que le pipeline CI/CD existe et tourne, ou est-ce qu'ils déploient en poussant sur main ? Est-ce que les tests unitaires sont là parce qu'ils ont du sens, ou parce que l'IA les a générés en masse pour gonfler la couverture ?
La vraie question, celle qui tranche, c'est la suivante : est-ce que l'équipe comprend ce qu'elle a construit ?
Dans le cas d'OpenClaw, la réponse était visiblement non, du moins sur la partie sécurité. Le créateur l'a dit lui-même. Et OpenAI a quand même signé, parce que la valeur était ailleurs.
La grille que je propose
Pour les acquéreurs qui veulent adapter leur due diligence à cette nouvelle réalité, voici les cinq axes que je recommande aujourd'hui.
Le premier, c'est la maîtrise de la stack. Demandez une démo live, pas préparée. Faites expliquer les choix d'architecture par ceux qui les ont faits. Si l'équipe ne peut pas défendre ses décisions techniques sans consulter le code, c'est un signal.
Le deuxième, c'est l'audit de sécurité par un tiers. Le code généré par IA a des patterns de failles récurrents. Un auditeur spécialisé les repère. C'est devenu non négociable, surtout sur les projets qui ont grandi vite.
Le troisième, c'est l'évaluation de la dette technique invisible. Les dépendances fragiles, les frameworks à la mode qui seront abandonnés dans dix-huit mois, le code trop verbeux qui multiplie la surface d'attaque. Le vibe coding produit du code qui fonctionne, mais qui est souvent surdimensionné et mal optimisé.
Le quatrième, c'est l'analyse de l'intention derrière l'usage de l'IA. Est-ce que l'équipe utilise l'IA pour aller plus loin, pour augmenter sa capacité de création ? Ou est-ce qu'elle l'utilise pour remplacer une expertise qu'elle n'a jamais eue ? La première approche crée de la valeur durable. La seconde crée de la dette technique déguisée en productivité.
Le cinquième, c'est la capacité à maintenir et à faire évoluer. Un projet « vibe codé » qui ne peut être maintenu que par son créateur original, avec les mêmes prompts et les mêmes outils, c'est un point de défaillance unique déguisé en innovation.
L'ère des créatifs, avec un filet de sécurité
Le vibe coding est une avancée formidable. C'est l'imprimerie du code, et comme l'imprimerie, il va transformer notre rapport à la création logicielle. Des gens qui n'auraient jamais pu construire un produit il y a deux ans peuvent aujourd'hui le faire en un week-end. C'est l'heure des créatifs, et c'est une bonne nouvelle.
Mais l'histoire d'OpenClaw nous rappelle que créer vite et créer bien sont deux choses différentes. Et que notre rôle d'évaluateur, c'est justement de faire la différence entre les deux.
OpenAI a les moyens de transformer un projet troué en produit sécurisé. La plupart des acquéreurs n'ont pas ce luxe. Quand vous évaluez une cible tech en 2026, ne vous laissez pas éblouir par les étoiles GitHub et la croissance virale. Regardez sous le capot. Posez les questions qui fâchent. Et rappelez-vous qu'un produit qui séduit les utilisateurs mais effraie les chercheurs en sécurité, c'est un passif autant qu'un actif.
La due diligence tech n'est pas morte. Elle doit juste apprendre à évaluer un monde où le code est devenu jetable, mais où le talent, la vision et la communauté ne le sont pas.
Pour voir comment ces principes s'appliquent concrètement au B2G, découvrez mon retour d'expérience sur la transition B2B vers B2G avec aquagir et Numérique360. Besoin d'un regard extérieur sur une opération M&A ou une due diligence tech ? Parlons-en.
