Heal.dev lève 4 M€ pour traquer les bugs que la revue de code rate

La jeune pousse française Heal.dev a annoncé le 10 novembre 2026 une levée de 4 millions d’euros auprès de Mango Capital et d’Alven destinée à renforcer son produit, ses équipes d’ingénierie et sa commercialisation en Europe. Son agent recherche des anomalies en faisant fonctionner une application : il vise les défauts qu’une lecture des modifications du code peut laisser passer.

Le portrait publié par Brief IA le même jour rappelle que l’entreprise, créée en 2023, travaillait d’abord sur l’automatisation des tests et fait état d’une douzaine de jeunes entreprises clientes. Le financement accompagne ainsi un déplacement de son activité vers la recherche de défauts dans le produit exécuté. Pour les petites équipes qui produisent du code plus vite avec des assistants, la vérification des parcours existants reste une tâche distincte de la création de nouvelles fonctions.

Ce que financent les 4 millions d’euros

Le financement doit servir à améliorer les capacités de l’agent et à étoffer les équipes chargées du produit et de l’ingénierie. L’autre axe annoncé est le développement commercial européen. Les informations publiées ne détaillent ni la répartition de la somme entre ces postes ni un calendrier d’ouverture pays par pays.

Ce choix répond à une difficulté concrète du développement logiciel : une modification localisée peut changer le résultat d’un parcours qui traverse plusieurs composants, données ou services. La revue d’une demande de fusion examine surtout ce qui a été modifié, alors que l’utilisateur rencontre le comportement de l’application entière. Automatiser cette seconde vérification pourrait donner à une petite équipe davantage de défauts reproductibles à corriger sans lui demander de prévoir chaque scénario à l’avance. La valeur de cette approche dépendra de la fidélité de l’environnement où les parcours sont exécutés.

Un agent qui exécute le produit et reproduit les défauts

La présentation officielle de Heal décrit un agent qui cartographie les fonctions d’une application, construit un bac à sable proche de son environnement de production, puis met à l’épreuve des anomalies possibles. Son exploration couvre les comportements, les vulnérabilités accessibles pendant l’exécution et les problèmes de performance. Chaque défaut retenu est accompagné d’un test en échec destiné à reproduire le comportement observé.

Le bac à sable permet de contrôler les données et de simuler certaines dépendances externes. Un service de paiement ou une interface tierce peut ainsi répondre lentement, échouer ou renvoyer une réponse inattendue pendant qu’un parcours est testé. L’agent peut partir d’un soupçon relevé dans le code, mais il ne transmet comme défaut que ce qu’il parvient à provoquer dans l’application exécutée. Cette étape transforme une alerte potentielle en cas vérifiable par l’équipe.

La démonstration du service montre un code promotionnel expiré que le panier présente comme accepté, avec un total réduit, avant que le paiement ne facture le prix entier. Il s’agit d’un scénario de démonstration, sans client réel identifié. L’intérêt du test associé tient à cette succession précise d’états : il permet de constater le décalage entre le panier et le paiement, puis de vérifier après correction que le même parcours aboutit au résultat attendu.

Une place distincte dans la chaîne de contrôle

Un test automatisé classique rejoue un scénario que l’équipe a défini. Il protège efficacement un comportement connu, mais ne cherche pas de lui-même une anomalie dans un parcours qui n’a jamais été décrit. La revue de code, humaine ou automatisée, intervient au moment où une modification est proposée : elle peut repérer un problème de logique, une pratique risquée ou une incohérence avant l’exécution. L’exploration dynamique de Heal part, elle, du produit en fonctionnement et tente de faire apparaître un défaut observable.

Cette différence explique à la fois l’intérêt et la limite du service. Un agent capable de traverser l’interface, les API et leurs dépendances peut relier des composants que la modification examinée séparément ne réunit pas. En revanche, une configuration d’intégration continue, un script de migration ou une règle interne de style peut appeler une revue du code sans produire de défaut dans un parcours utilisateur. La preuve fournie par Heal concerne donc le comportement qu’il a pu exécuter dans son bac à sable, avec les données et les services que celui-ci reproduit.

Ce que signifie réellement le résultat de 70 %

Dans son benchmark publié en octobre 2026, Heal compare son exécution complète à trois robots de revue sur cinq applications et 236 demandes de fusion : parmi les 202 défauts touchant l’utilisateur que son agent a prouvés sur le code concerné, 141, soit 70 %, n’avaient été signalés par aucun robot. Les outils comparés étaient CodeRabbit, Greptile et cubic. Ce pourcentage décrit les défauts découverts et reproduits par Heal dans ce protocole interne ; il ne mesure ni tous les bugs présents dans ces applications ni la performance générale des outils sur d’autres projets.

Les demandes de fusion ont été rejouées dans des copies privées des projets, avec les robots installés, tandis que l’agent exécutait les applications avant et après les séries de modifications. Deux bases de code appartenaient à l’entreprise et étaient anonymisées ; les trois autres correspondaient à des projets ouverts. Un modèle de langage rapprochait les alertes des robots des défauts reproduits par Heal, après calibrage sur un échantillon examiné manuellement. Sur l’une des applications, tous les robots n’ont pas traité le même nombre de demandes de fusion.

Le périmètre choisi compte autant que le résultat. Les alertes des robots n’ont pas toutes fait l’objet d’une vérification de leur pertinence, et certains fichiers qu’ils examinent restent hors de l’exploration de Heal. Le protocole montre une différence entre des commentaires sur le code et des défauts reproduits à l’exécution, mais ne constitue pas une étude indépendante établissant qu’un outil remplace l’autre. Pour les équipes clientes, la portée du service se jouera dans la couverture réelle de leurs parcours, de leurs données et de leurs dépendances.

À lire aussi :

• Canva ou Adobe Express : l’interface compte plus que les fonctions
• Anthropic assouplit Claude pour la biologie, après vérification des équipes
• Freelances face à l’IA : produire moins, vérifier plus, se former pour survivre