Builder.ai : quand la promesse d’une IA de code se heurte au travail humain

Builder.ai vendait une idée particulièrement séduisante : permettre à une entreprise de faire développer une application avec la facilité d’une commande de pizza. À la place d’un long projet informatique mené par une équipe de développeurs, la start-up londonienne mettait en avant Natasha, une intelligence artificielle censée automatiser la production de code. Au 4 juin 2025, cette promesse est au cœur d’une affaire qui mêle intervention humaine massive, prévisions commerciales contestées et difficultés financières.

Le point le plus frappant n’est pas qu’une entreprise technologique emploie des ingénieurs. C’est normal, y compris dans l’intelligence artificielle. Ce qui interpelle est l’écart allégué entre l’image d’un outil capable de programmer de manière autonome et le rôle qu’auraient joué 700 travailleurs humains, principalement en Inde, pour écrire le code livré aux clients. Cette distinction est essentielle pour comprendre ce que l’affaire Builder.ai dit des promesses de l’IA, de la confiance des investisseurs et de la place du travail humain caché derrière certains services numériques.

Builder.ai promettait de simplifier radicalement le développement d’applications

Fondée à Londres en 2016, Builder.ai s’était fait connaître avec une ambition claire : rendre la conception d’applications sur mesure plus accessible aux organisations qui ne disposent pas d’une grande équipe informatique. Le développement logiciel classique peut être coûteux et lent. Il faut recueillir les besoins, choisir une architecture technique, écrire le code, tester l’application, corriger les erreurs et assurer sa maintenance.

La promesse de Builder.ai consistait à industrialiser une partie de ce processus. La société présentait Natasha comme une IA capable d’aider à produire une application à partir des choix du client. L’idée n’était pas seulement de fournir un outil d’assistance aux programmeurs, mais de réduire considérablement la complexité visible pour l’acheteur.

Une telle promesse a de quoi séduire. Les entreprises cherchent des solutions plus rapides pour créer des outils internes, des applications commerciales ou des services mobiles. Les investisseurs, eux, voient dans l’automatisation du code un marché potentiellement immense. Builder.ai a ainsi attiré des financements de premier plan, notamment de Microsoft et d’investisseurs du Qatar. Sa valorisation a atteint 1,5 milliard de dollars, un seuil qui lui a valu le statut de licorne, terme employé pour les jeunes entreprises non cotées valorisées à plus d’un milliard de dollars.

Que sait-on du rôle des 700 programmeurs humains ?

Les éléments rendus publics le 31 mai 2025 décrivent un dispositif dans lequel Natasha dépendait du travail d’environ 700 personnes, principalement des travailleurs indiens. Selon ces révélations, ces ingénieurs rédigeaient manuellement les lignes de code nécessaires aux projets des clients, pour une rémunération située entre 8 et 15 dollars de l’heure.

Présenté ainsi, le cas ne revient pas à dire qu’aucune technologie n’était utilisée. La création d’un logiciel moderne s’appuie presque toujours sur des outils d’automatisation, des bibliothèques de code réutilisables, des plateformes de tests et, de plus en plus, des assistants génératifs. Mais il soulève une question beaucoup plus précise : quelle part du résultat final venait réellement de l’outil présenté comme de l’IA, et quelle part reposait sur le travail de programmeurs ?

Dans de nombreux produits numériques, des humains interviennent en arrière-plan. Ils peuvent annoter des données pour entraîner des modèles, vérifier la qualité de réponses produites automatiquement, traiter les cas complexes ou assurer une assistance client. Ce fonctionnement, souvent qualifié d’approche « humain dans la boucle », n’a rien d’illégal ni de nécessairement trompeur. Il peut même être indispensable lorsque les erreurs ont un coût élevé.

La difficulté commence lorsque le degré d’autonomie annoncé ne correspond pas à la réalité opérationnelle. Si un client pense acheter un logiciel qui génère automatiquement son application, mais que l’essentiel du travail est en fait réalisé par une équipe humaine, il doit pouvoir le savoir. Cette information compte pour évaluer le prix, les délais, la confidentialité du projet, les responsabilités en cas de défaut et la capacité de l’entreprise à changer d’échelle.

Pourquoi le recours à des humains n’est pas, à lui seul, une fraude

L’expression « fausse IA » est souvent utilisée dès qu’un service présenté comme intelligent s’appuie sur des opérateurs humains. Elle peut toutefois simplifier abusivement la situation. Toute IA est conçue, entraînée, testée et supervisée par des personnes. Les systèmes les plus avancés ne sont pas magiques : ils dépendent de données, d’infrastructures informatiques et de procédures de contrôle élaborées par des équipes humaines.

Le vrai critère est la transparence. Une société peut très bien proposer un service hybride, dans lequel une plateforme automatise certaines tâches tandis que des spécialistes effectuent le reste. Elle doit alors être claire sur plusieurs points :

• les tâches effectivement prises en charge par l’outil ;
• celles qui sont réalisées ou vérifiées par des humains ;
• l’emplacement et les conditions de travail des équipes mobilisées ;
• les garanties apportées au client sur la confidentialité et la qualité ;
• les limites de l’automatisation revendiquée.

Dans le cas de Builder.ai, les révélations sont graves parce qu’elles suggèrent un décalage entre le discours commercial autour de Natasha et les méthodes concrètes de production. Elles ne permettent pas, à elles seules, de trancher toutes les questions de responsabilité juridique. En revanche, elles posent un problème de confiance majeur : les clients et les investisseurs ont besoin d’informations exactes pour décider en connaissance de cause.

La crise financière a fait tomber le récit de croissance

La controverse technologique intervient alors que Builder.ai traversait déjà une crise financière. En 2025, l’entreprise a été contrainte de reconnaître que ses projections de ventes étaient très éloignées de la réalité. Pour une start-up en forte croissance, les prévisions occupent une place centrale : elles servent à lever des fonds, recruter, conclure des partenariats et justifier une valorisation élevée.

Lorsque les revenus attendus ne se matérialisent pas, le modèle se fragilise rapidement. Les coûts de développement, de vente et de fonctionnement continuent, tandis que les liquidités se raréfient. Dans le cas de Builder.ai, l’un de ses principaux créanciers a bloqué 37 millions de dollars d’actifs. Cette décision a contribué à précipiter la société vers une procédure d’insolvabilité.

Il faut distinguer deux aspects qui se renforcent mutuellement. D’un côté, une entreprise peut échouer commercialement sans avoir menti sur sa technologie. De l’autre, un doute sur les capacités réelles d’un produit peut rendre beaucoup plus difficile la défense de prévisions financières ambitieuses. Ici, la remise en cause de la promesse d’automatisation intervient au moment même où le récit de croissance s’effondre.

Microsoft et les investisseurs face à la question de la vérification

La présence de Microsoft et d’investisseurs qataris parmi les soutiens de Builder.ai donne à l’affaire une portée qui dépasse la seule start-up. Lorsqu’un acteur établi investit dans une jeune pousse ou signe un partenariat, sa participation est souvent perçue comme un signal de crédibilité. Or un investissement ne signifie pas nécessairement que chaque affirmation commerciale, chaque prévision de vente ou chaque détail du fonctionnement technique a été audité de façon exhaustive.

Pour les investisseurs, l’affaire rappelle l’importance de la vérification préalable, appelée due diligence dans le monde de la finance. Cette étape ne devrait pas s’arrêter aux présentations de produits ou aux démonstrations soigneusement préparées. Dans une entreprise qui vend de l’automatisation, elle implique notamment d’examiner les processus de production réels, le coût du travail humain mobilisé, les indicateurs de satisfaction des clients et la cohérence entre les revenus déclarés et les contrats effectivement signés.

Pour les grandes entreprises partenaires, le sujet est aussi réputationnel. Elles doivent pouvoir expliquer la nature de leur lien avec une start-up et les contrôles appliqués avant d’associer leur nom à une technologie. Le cas Builder.ai pourrait donc encourager une exigence accrue de preuves techniques, surtout pour les produits d’IA qui promettent de remplacer des tâches habituellement réalisées par des professionnels.

Comment évaluer une promesse d’IA sans être spécialiste ?

Les clients ne disposent pas toujours des moyens d’auditer le code ou le modèle utilisé par un fournisseur. Ils peuvent néanmoins poser des questions simples et révélatrices avant de signer. L’objectif n’est pas d’exiger qu’un produit soit entièrement automatisé, mais de comprendre honnêtement ce qui est acheté.

Une entreprise qui envisage un outil de création automatisée peut demander une démonstration sur un cas proche de son besoin réel, plutôt qu’une présentation générique. Elle peut aussi demander quel pourcentage du travail est effectué par des humains, comment sont traitées les données confiées au prestataire, qui assume la responsabilité en cas de bug, et comment les coûts évoluent lorsque le projet devient plus complexe.

Les indicateurs les plus utiles ne sont pas toujours les mots à la mode. Il est plus instructif de savoir combien de temps prend réellement la livraison d’une application, quel est le niveau de personnalisation possible, comment sont gérées les mises à jour et combien d’interventions humaines sont nécessaires. Une réponse précise à ces questions inspire davantage confiance qu’une promesse vague d’IA révolutionnaire.

Ce qu’il faut surveiller après l’affaire Builder.ai

Au 4 juin 2025, l’effondrement de Builder.ai est un avertissement pour un secteur où l’étiquette IA peut faire monter très vite l’attention, les financements et les valorisations. L’affaire ne démontre pas que les outils d’IA pour programmer sont inutiles. Au contraire, les assistants de code progressent rapidement et peuvent accélérer certaines étapes du développement. Mais ils ne doivent pas être confondus avec une capacité universelle à concevoir, livrer et maintenir n’importe quelle application sans intervention humaine substantielle.

La suite dépendra de plusieurs éléments : la manière dont seront établis les faits sur le fonctionnement de Natasha, le traitement de la procédure d’insolvabilité, les conséquences pour les salariés et prestataires concernés, ainsi que les éventuelles réponses des investisseurs et partenaires. Plus largement, les entreprises d’IA devront apprendre à décrire leurs produits avec davantage de précision.

Le principal enseignement est peut-être le plus simple : dans la technologie comme ailleurs, l’innovation n’exonère pas de la preuve. Dire qu’un outil utilise de l’IA ne renseigne ni sur son degré d’autonomie, ni sur sa fiabilité, ni sur les personnes qui contribuent réellement au résultat. Pour les clients, les travailleurs et les investisseurs, cette transparence n’est pas un détail marketing. C’est une condition de confiance.