Défragilisation

De quoi il s'agit

Défragiliser un code consiste à réduire, avant qu'un attaquant ne les trouve, le stock de failles exploitables qu'il contient. Le travail se fait en boîte blanche, à partir du code source que l'organisation possède : des agents le relisent un type de faille à la fois, chaque faille trouvée est prouvée par un test qui échoue sur le code actuel, un correctif est livré avec le test qui passe, et l'analyse est relancée à chaque nouvelle génération de modèles. Le terme désigne une politique tenue dans le temps, avec un registre daté de chaque passage, plutôt qu'un audit rendu à une date donnée.

La défragilisation applique à votre propre code les capacités de la recherche de vulnérabilités par IA documentées en 2026 sur l'open source. Le défenseur y dispose d'un avantage que l'attaquant n'a pas : il possède déjà le code source, quand l'autre doit le reconstituer depuis le binaire. Cet avantage ne vaut que s'il est utilisé en premier, comme l'explique ce que la rétro-ingénierie par agents change pour une équipe sécurité.

Pourquoi maintenant

L'IA a rendu l'écriture d'un exploit rapide et bon marché, et la correction n'a pas suivi. Mandiant mesure le délai moyen entre la sortie d'un correctif et la première exploitation de la faille : 63 jours en 2018-2019, moins 7 jours estimés pour 2025 dans M-Trends 2026, l'exploitation précédant désormais le correctif en moyenne. Côté correction, le DBIR 2026 de Verizon fixe à 43 jours le délai médian pour corriger entièrement une faille du catalogue KEV de la CISA. Ces séries et leurs limites sont détaillées dans l'exploit n'est plus le goulot.

Ce raisonnement porte sur des logiciels d'éditeurs : une faille publiée, un correctif livré, un délai pour l'appliquer. Votre code interne n'a pas d'éditeur. Personne ne publiera de CVE pour votre back-office, personne ne livrera de correctif pour l'application métier écrite par un prestataire parti depuis des années. Votre délai de correction commence le jour où quelqu'un trouve la faille, et ce quelqu'un dispose des mêmes agents que vous pour lire le code ou le binaire.

Quel code en premier

Trois catégories de code n'ont personne pour les défragiliser. L'open source est relu par des chercheurs et des chasseurs de primes ; le code neuf passe par les contrôles des outils de développement. Le legacy, les applicatifs internes et le code sous-traité ont été audités une fois, à la mise en production, puis oubliés au motif qu'ils ne seraient pas attaqués. Les modèles trouvent pourtant des failles anciennes dans le code le plus relu, et ce qu'un modèle trouve dans l'open source, il le trouve dans votre code interne.

L'ordre de passage suit l'ancienneté. Le legacy d'abord : écrit avant les outils d'analyse actuels, jamais relu avec un modèle capable de le lire en entier. Puis les applicatifs internes, back-offices, portails et API métier que vous possédez, que vous pouvez corriger et qu'aucun chercheur extérieur ne verra. Puis le code sous-traité, livré et recetté depuis des années, dont vous avez le code mais rarement la lecture. Quand un sous-système accumule trop de bugs prouvés, la réécriture devient abordable avec les agents, et le chantier rejoint la modernisation du legacy.

Comment on défragilise

« Trouve des failles dans ce dépôt » ne donne rien d'exploitable. La méthode découpe le travail : un projet, un type de faille, une chaîne d'agents qui cherche, reproduit, corrige et prouve, un bug à la fois. Une conclusion d'agent n'entre dans un rapport qu'avec sa preuve ou avec le test qui la démontre ; la revue des sorties d'agents est décrite dans lire une sortie REA, et les outils de lecture de binaires dans la fiche REA.

• Chercher. Un agent parcourt le projet avec une seule question : où ce type de faille peut-il se produire ?
• Prouver. Chaque hypothèse devient un test qui échoue sur le code actuel. Sans test, pas de bug remonté.
• Corriger. Un correctif, le test qui passe, et le reste de la suite qui passe toujours. Un bug à la fois.
• Rendre. Chaque faille est livrée prouvée par un test, avec ou sans son correctif ; le client choisit où s'arrêter.
• Consigner. Pour chaque application : les types de failles cherchés, le modèle utilisé, la date, les bugs prouvés et les correctifs livrés.
• Relancer. Ce qu'un modèle ne voyait pas, le suivant peut le voir. L'analyse du stock repart à chaque nouveau modèle, le legacy en premier.

Frontières avec les pratiques voisines

La défragilisation sort du patch management, qui applique les correctifs livrés par les éditeurs : ici, aucun éditeur ne livre rien, le correctif se produit en interne. Elle se distingue aussi de la réduction d'accessibilité, la réponse retenue quand un logiciel ne peut pas être corrigé (appliance exposée, système industriel, dispositif médical) : segmentation, isolation, filtrage, procédure manuelle de repli. Ces deux réponses restent nécessaires pour le logiciel que vous achetez ; la défragilisation couvre le code que vous possédez.

Elle se distingue enfin du test d'intrusion, de la red team et des attaques sur agents conversationnels, qui travaillent en boîte noire, de l'extérieur et à une date donnée. Les deux postures se complètent : le pentest teste ce qui est exposé, la défragilisation lit le code lui-même. Le rapport ne parle que de sécurité : la dette technique, la lisibilité et l'architecture ne sont pas notées.

La position SFEIR

SFEIR porte cette pratique dans son offre AI Cyber : défragiliser le code existant en boîte blanche, applicatifs internes et legacy, un type de faille à la fois, chaque faille prouvée par un test et livrée avec son correctif, l'analyse relancée à chaque nouveau modèle. Le code reste sous le contrôle du client : sa politique de sécurité décide du modèle et de l'endroit où il s'exécute, infrastructure propre, hébergeur souverain ou fournisseur aux conditions validées, et, quand elle l'exige, l'analyse tourne réseau coupé avec un modèle à poids ouverts. Le registre daté qui en résulte est le genre de trace que le Cyber Resilience Act demande aux fabricants de tenir sur leurs produits. Le pentest externe et la red team sont hors périmètre : SFEIR ne les fait pas et indique qui les fait.