Digma veut détecter les défauts de code avant qu’ils ne ralentissent les applications

Une application qui devient lente au moment d’un paiement, un service qui consomme soudainement trop de ressources cloud ou une base de données saturée sont rarement des incidents sans signes avant-coureurs. Pourtant, ces signaux sont souvent noyés dans la masse des données techniques, ou ne sont examinés qu’une fois le problème visible pour les utilisateurs. C’est sur cet angle que Digma fonde son moteur d’observabilité préventive, présenté comme un moyen de détecter les défauts de comportement d’un logiciel avant qu’ils ne se transforment en panne ou en dégradation de service.

L’enjeu gagne en importance avec la diffusion des assistants de programmation alimentés par l’intelligence artificielle. Ces outils peuvent accélérer l’écriture de fonctions, de tests ou de documentation, mais ils augmentent aussi le volume de code à contrôler. Un programme peut être syntaxiquement correct, réussir ses tests de base et malgré tout se révéler lent, coûteux ou difficile à faire monter en charge dans des conditions réelles. L’ambition de Digma est précisément d’observer cette réalité d’exécution, plutôt que de se limiter à l’examen statique du code.

Digma mise sur une observabilité qui intervient avant l’incident

Digma a lancé un moteur d’analyse baptisé APO, pour « observabilité préemptive » dans la publication d’origine. Son objectif est de vérifier le code, d’identifier des problèmes potentiels et de proposer des pistes de correction en s’appuyant sur des techniques d’intelligence artificielle.

Le mot « observabilité » désigne la capacité à comprendre l’état interne d’un système informatique à partir des signaux qu’il produit. Dans une application moderne, ces signaux comprennent notamment les journaux d’événements, les métriques de consommation et les traces. Une trace suit le parcours d’une requête à travers les différents composants d’un logiciel, par exemple lorsqu’un internaute ouvre une page, ajoute un produit à son panier puis règle sa commande.

Cette approche est différente d’une simple surveillance. Le monitoring classique répond souvent à la question « que se passe-t-il maintenant ? », en affichant par exemple une hausse du temps de réponse ou un taux d’erreur. L’observabilité cherche davantage à expliquer « pourquoi cela se produit-il ? ». Digma entend aller plus loin en tentant de repérer les symptômes avant qu’ils ne déclenchent une alerte majeure ou une interruption de service.

Selon la publication d’origine, l’algorithme de Digma recourt à la détection d’anomalies et à la correspondance de motifs. Il analyse les données disponibles pour anticiper notamment les temps de réponse des applications et l’utilisation des ressources. L’examen des données de traçage doit aider à localiser l’origine d’un problème, afin que l’équipe technique puisse agir plus tôt.

Pourquoi le code généré par IA pose aussi un défi de qualité

L’IA générative est désormais capable de proposer rapidement du code à partir d’instructions en langage naturel. Pour les développeurs, ce peut être un gain de temps appréciable sur les tâches répétitives ou lors de l’exploration d’une bibliothèque logicielle. Mais la rapidité de génération ne garantit ni la robustesse, ni la sécurité, ni la performance du résultat.

La publication d’origine évoque une étude associée à l’université de Stanford, publiée en 2023, selon laquelle les développeurs utilisant des assistants de code fondés sur l’IA sont plus susceptibles de produire des bogues. La publication scientifique citée porte plus précisément sur la sécurité du code : elle examine les effets d’assistants de programmation sur la propension des utilisateurs à écrire du code vulnérable. Sa leçon est utile au-delà du seul sujet de la sécurité : une suggestion produite par une IA peut sembler convaincante tout en introduisant un défaut que l’utilisateur n’a pas immédiatement identifié.

Le phénomène est d’autant plus significatif que les grandes entreprises intègrent ces outils à leurs processus. L’article rappelle que Google a indiqué que plus de 25 % de son nouveau code était généré par IA. Ce chiffre ne signifie pas que le logiciel est mis en production sans validation humaine. Il illustre en revanche une transformation concrète du travail : les ingénieurs doivent évaluer un volume croissant de modifications, y compris lorsqu’elles proviennent d’outils qui accélèrent fortement la phase d’écriture.

Les risques ne se résument pas à une erreur de logique. Un fragment de code peut aussi :

• multiplier inutilement les appels à une base de données ;
• ralentir une opération quand le nombre d’utilisateurs augmente ;
• déclencher une consommation excessive de calcul ou de mémoire ;
• provoquer des réponses trop lentes pour respecter les objectifs de service ;
• compliquer les investigations en cas d’incident, s’il est mal intégré au reste de l’application.

Dans ce contexte, la promesse de Digma n’est pas de rendre le code généré par IA infaillible. Elle consiste à fournir une couche d’analyse supplémentaire, tournée vers le comportement réel de l’application.

Des défauts qui coûtent du temps aux équipes d’ingénierie

Nir Shafrir, directeur général de Digma, insiste dans la publication d’origine sur le décalage entre les ressources consacrées à la performance et le nombre de problèmes qui n’apparaissent qu’à un stade tardif du cycle de production. Le constat concerne aussi bien le code écrit manuellement que celui assisté par IA.

L’article estime que les équipes d’ingénierie passent entre 20 et 40 % de leur temps à résoudre ces difficultés. Cette fourchette montre combien les travaux de correction peuvent peser sur la capacité d’une entreprise à développer de nouvelles fonctionnalités. Lorsqu’un incident survient, l’équipe ne se contente pas de modifier une ligne de code. Elle doit d’abord reproduire le comportement, consulter les traces, identifier le service fautif, mesurer les effets d’une correction, puis déployer celle-ci sans créer de régression.

Les secteurs où chaque ralentissement peut se traduire par une perte de revenu sont particulièrement concernés. L’article cite le commerce de détail, la fintech et l’e-commerce. Dans ces environnements, un temps de réponse dégradé lors d’un pic de fréquentation peut faire échouer une transaction. Il peut également conduire à ne pas respecter un accord de niveau de service, souvent désigné par l’acronyme SLA.

Un SLA fixe des engagements mesurables entre un fournisseur et son client, par exemple sur la disponibilité ou la rapidité d’un service. Une violation de ces engagements peut avoir des conséquences contractuelles, financières ou réputationnelles. Prévenir les causes techniques d’une dégradation est donc un sujet opérationnel, mais aussi économique.

Du signal technique à une correction possible

Le principe de l’observabilité préventive repose sur l’étude des comportements d’exécution. Il ne s’agit pas seulement de signaler qu’un indicateur est mauvais, mais d’identifier la séquence qui pourrait conduire à un incident. Digma met notamment en avant la compréhension de ces comportements et la suggestion de solutions face à des problèmes de performance ou de passage à l’échelle.

Le passage à l’échelle, aussi appelé scalabilité, désigne la capacité d’un système à absorber une hausse de charge sans dégrader le service. Une application peut fonctionner parfaitement avec quelques dizaines d’utilisateurs et connaître des difficultés avec plusieurs milliers de connexions simultanées. Des opérations trop coûteuses, invisibles à petite échelle, deviennent alors des goulets d’étranglement.

L’intérêt d’un outil de ce type dépend donc fortement de la qualité des données observées et de son intégration au travail quotidien. Une alerte trop vague est peu utile. À l’inverse, une analyse qui relie un ralentissement à une portion précise du parcours applicatif peut aider un développeur à prioriser une correction.

Monitoring et observabilité préventive : deux approches complémentaires

Les plateformes de monitoring sont indispensables : elles permettent de savoir rapidement qu’un système est en difficulté, de suivre des indicateurs et de déclencher des alertes. Digma ne remet pas en cause ce besoin. Sa différenciation revendiquée tient au moment où l’analyse intervient et au niveau de recommandation recherché.

Roni Dover, directeur technique et cofondateur de Digma, présente cette logique comme un basculement d’une posture réactive vers une démarche proactive. L’idée est de ne pas attendre qu’un produit soit déjà affecté en production pour examiner certains problèmes de performance ou de capacité.

Cela ne dispense toutefois pas d’autres pratiques de qualité. Les tests automatisés vérifient que le logiciel respecte les comportements attendus. Les revues de code permettent à d’autres développeurs d’examiner une modification. Les tests de charge simulent une forte utilisation. Enfin, les équipes de sécurité doivent évaluer les vulnérabilités possibles. L’observabilité ajoute une information différente : ce que fait réellement le système dans son environnement d’exécution.

Réduire les défaillances peut aussi limiter la facture cloud

La performance est souvent associée au confort des utilisateurs, mais elle a également un effet direct sur les coûts d’infrastructure. Un service mal optimisé peut utiliser davantage de puissance de calcul, de mémoire ou de requêtes vers une base de données qu’il n’en faudrait. Dans une infrastructure cloud, où ces ressources sont facturées à l’usage, le surcoût peut s’accumuler rapidement.

La publication d’origine souligne que la détection en amont des risques peut contribuer à réduire les coûts liés au cloud, en minimisant les défaillances et les goulets d’étranglement. Cette promesse doit être comprise avec prudence : un outil d’analyse ne réduit pas automatiquement une facture. Il fournit des éléments pour que les équipes identifient des inefficacités et décident, ou non, de les corriger.

Digma indique avoir clôturé une levée de fonds de 6 millions de dollars. Ce financement doit soutenir ses futures innovations et renforcer sa position sur le marché de l’observabilité, un domaine devenu stratégique avec la multiplication des architectures distribuées, des services cloud et des usages de l’IA dans la programmation.

Ce qu’il faut surveiller avec l’industrialisation du code assisté par IA

Au 9 février 2025, le développement logiciel entre dans une phase où produire du code n’est plus le seul défi. Les assistants génératifs peuvent raccourcir le temps nécessaire pour créer une fonctionnalité, mais ils rendent d’autant plus cruciale la capacité à vérifier l’impact de cette fonctionnalité une fois exécutée avec de vraies données et de vrais utilisateurs.

Pour les entreprises, la question centrale sera la fiabilité des outils de prévention : savent-ils distinguer une variation normale d’un risque réel ? Leurs recommandations sont-elles compréhensibles et suffisamment précises pour être appliquées ? Et surtout, s’intègrent-ils sans surcharger les équipes d’alertes supplémentaires ?

Les outils comme celui de Digma répondent à une attente claire : déplacer une partie de l’effort depuis la réparation coûteuse des incidents vers leur détection précoce. Leur valeur se mesurera moins à la promesse d’une IA qui corrige tout seule qu’à leur capacité à donner aux ingénieurs les bons signaux, au bon moment, pour livrer des applications plus stables.