Breken veut détecter les bugs avant les utilisateurs en simulant la vie réelle des logiciels

Breken simule des conditions de production pour détecter les bugs avant les utilisateurs. Sur ESCAPES, il identifie 76 défauts sur 235.

Les tests automatisés vérifient généralement les situations que les développeurs ont anticipées. Mais certains bugs n'apparaissent qu'après plusieurs semaines d'utilisation, lorsqu'un service externe tombe en panne, que deux personnes modifient un même document ou qu'une opération bancaire est interrompue au mauvais moment. Avec Breken, une jeune entreprise spécialisée dans l'ingénierie logicielle propose de reproduire ces conditions avant que les utilisateurs n'y soient confrontés. Son système exécute les applications dans des environnements isolés, simule leurs utilisateurs et leurs dépendances, puis recherche les défaillances pour en préparer des correctifs. Dans une évaluation portant sur 33 logiciels open source, Breken affirme avoir retrouvé 76 bugs sur 235, contre 37 pour Claude Fable 5.1 et 28 pour GPT-6 Astra. Les bugs que les tests classiques ne voient pas

L'accélération de la production de logiciels par les assistants de programmation ne supprime pas les difficultés rencontrées après leur déploiement. Un programme peut passer ses tests unitaires, satisfaire une revue de code et fonctionner correctement lors d'une démonstration, tout en se comportant autrement lorsque les données s'accumulent ou que plusieurs opérations surviennent simultanément. Les défauts les plus difficiles à reproduire dépendent parfois moins d'une erreur évidente dans le code que d'une combinaison d'événements rarement rencontrée pendant le développement.

Breken cherche à intervenir dans cet espace entre la validation technique et l'utilisation réelle. L'entreprise présente cette activité comme une forme de production engineering, c'est-à-dire une ingénierie qui ne se contente pas de vérifier ce qu'un logiciel devrait faire, mais cherche à observer comment il réagit aux conditions imprévues de son environnement. Plutôt que d'attendre qu'un client signale une anomalie, le système tente de provoquer des situations susceptibles de faire apparaître les mêmes problèmes.

L'idée ne consiste pas à remplacer les tests existants. Une revue de code reste adaptée pour identifier certaines erreurs logiques ou vérifier une modification avant son intégration. Les tests automatisés sont efficaces pour contrôler des comportements connus. Breken ajoute une autre étape : explorer le fonctionnement du logiciel lorsqu'il dispose déjà d'un historique, de plusieurs utilisateurs, de tâches en attente et de services externes qui ne se comportent pas toujours comme prévu. Reconstituer une application et lui donner une histoire

Pour effectuer ces vérifications, Breken exécute une copie de l'application sur sa propre infrastructure. Les bases de données, files de tâches, services de paiement, systèmes de messagerie et autres dépendances sont représentés à l'intérieur d'un environnement isolé. Le principe annoncé est de reproduire leurs comportements sans laisser les simulations communiquer directement avec les systèmes extérieurs.

Le logiciel commence par construire un état de fonctionnement crédible. Il crée des comptes, des enregistrements, des opérations en cours et des situations héritées d'une utilisation prolongée. Une base de données presque vide ne révèle pas les mêmes problèmes qu'un service disposant de centaines de milliers d'enregistrements, d'abonnements renouvelés plusieurs fois et d'opérations interrompues. Breken cherche donc à faire apparaître des états qui résulteraient normalement de plusieurs mois d'activité.

L'entreprise met en avant une accélération du temps simulé pouvant atteindre 4 000 fois le temps réel. Sur sa démonstration, deux années de fonctionnement peuvent être explorées en quelques heures. Cette compression temporelle permet notamment de tester des dates d'expiration, des renouvellements, des changements de configuration ou des données qui évoluent lentement.

La simulation ne concerne pas seulement les services techniques. Breken crée aussi une population d'utilisateurs et d'agents logiciels disposant d'objectifs et de comportements différents. Un administrateur peut effectuer de nombreuses modifications à la suite, un utilisateur peut ouvrir plusieurs onglets sur le même document et un agent peut traiter automatiquement des demandes de remboursement. Ces comportements sont combinés à des interruptions réseau, des délais ou des changements d'état pour rechercher des défaillances. Modifier une seule condition pour comprendre la panne

Après avoir construit l'environnement, Breken explore différentes situations en faisant varier une condition à la fois : une réponse réseau perdue, une opération répétée, une connexion interrompue, un changement d'heure ou un déploiement lancé pendant un traitement. Le reste du scénario est maintenu identique afin de distinguer un problème reproductible d'un résultat accidentel.

Cette méthode permet de comparer une situation normale avec celle dans laquelle l'anomalie apparaît. L'entreprise prend notamment l'exemple d'un remboursement déclenché après une capture partielle de paiement. Dans le fonctionnement attendu, le montant remboursé doit correspondre à la somme réellement prélevée. Mais dans une configuration particulière, le système rembourse la totalité du montant initialement autorisé. En recréant l'opération dans les deux états, Breken peut identifier la condition responsable de l'erreur.

Lorsqu'un défaut est détecté, l'outil rassemble son état initial, les étapes permettant de le reproduire et les traces d'exécution. Il peut ensuite préparer une pull request de correction, afin qu'une équipe de développement examine la modification proposée avant de l'intégrer. L'objectif est de fournir une anomalie observable plutôt qu'un simple avertissement indiquant qu'une partie du code pourrait présenter un risque.

Le degré de preuve varie cependant selon les scénarios. Certaines anomalies peuvent être reproduites automatiquement et comparées à une exécution normale, tandis que d'autres nécessitent encore une interprétation ou une validation humaine. ESCAPES : 327 bugs réels issus