IA et cybersécurité : anticiper les failles du code
Comprenez comment l’IA accélère la recherche de vulnérabilités, pourquoi les correctifs manuels ne suffisent plus et comment préparer votre entreprise.
Quand l'IA accélère la recherche de failles, le vieux code devient un risque systémique
Une faille critique dans un langage utilisé par une grande partie du Web ne reste pas un souci isolé. Elle peut toucher des applications, des hébergeurs et des entreprises qui ne savent pas toujours quelles versions de leurs dépendances tournent en production. L'alerte récente autour de PHP - environ 70 % des sites, selon les chercheurs cités - l'a rappelé : certaines organisations ont même préféré mettre des sites hors ligne temporairement, le temps de corriger leurs systèmes.
L'IA change la donne surtout par l'accélération. Dans un épisode du podcast Equity, Tomer Schwartz, directeur technique chez Wiz, explique que des outils développés avec l'aide de l'IA ont permis de tester des dizaines de pistes en un week-end. Mais trouver une faille, ce n'est pas la fin du travail : il faut confirmer ce qu'elle permet vraiment, prévenir les équipes concernées, puis déployer un correctif sans déclencher une nouvelle panne.
Pour les entreprises, l'enjeu n'est donc pas de suivre toutes les annonces « choc ». C'est plutôt de savoir où se trouve le code vulnérable, qui peut agir, et comment réduire le temps entre la découverte et la correction. Voici comment aborder ce risque, surtout quand vos produits reposent sur des logiciels anciens ou sur des composants open source.
Comment l'IA change-t-elle la recherche de vulnérabilités ?
L'IA ne « découvre » pas les failles par intuition. Elle aide à explorer plus vite un espace de recherche vaste, répétitif et souvent mal documenté. Dans le cas évoqué par Schwartz, Wiz a utilisé des outils personnalisés pour mettre à l'épreuve des dizaines d'hypothèses en très peu de temps. Il estime que son équipe n'aurait pas trouvé ces vulnérabilités sans cette aide.
La nuance compte : ce n'est pas forcément la preuve qu'un modèle généraliste peut auditer seul un logiciel complexe. Tout dépend notamment de la qualité des hypothèses, des outils qui exécutent les tests, de la compréhension du code et de la capacité humaine à faire la différence entre un vrai signal et un faux positif.
De l'hypothèse au test, plus rapidement
Dans une recherche classique, un spécialiste formule une piste, prépare un environnement, exécute des tests, puis interprète le résultat. L'IA peut accélérer certaines étapes : proposer des cas à vérifier, générer des variantes de tests, ou aider à naviguer dans de grandes bases de code. Ensuite, des outils spécialisés peuvent confirmer si certaines pistes mènent à un comportement anormal.
Le gain principal, c'est la cadence. Une équipe peut examiner plus de chemins dans le même laps de temps. Mais cela ne garantit ni que chaque piste soit pertinente, ni que les résultats soient directement exploitables. Il faut toujours reproduire la faille, comprendre les conditions nécessaires, et estimer ce qu'un attaquant pourrait faire concrètement.
La même accélération profite aux défenseurs et aux attaquants
Une recherche plus rapide peut permettre aux mainteneurs de corriger plus tôt. Mais elle peut aussi réduire le temps dont disposent des acteurs malveillants pour repérer une faiblesse déjà présente dans un système exposé. En clair : l'IA ne rend pas automatiquement les organisations plus sûres. Elle accélère une partie de la course des deux côtés.
Pour les entreprises, la conséquence pratique tient en une idée : le délai de réaction devient plus important, mais ça ne sert à rien d'aller plus vite si vous ne savez pas quelles versions vous utilisez, ni qui est responsable des mises à jour. L'inventaire et la capacité à corriger restent le socle.
À retenir : l'IA augmente la vitesse de certaines tâches, quand l'équipe et le processus suivent. Elle ne remplace ni l'expertise sécurité, ni la validation technique, ni le déploiement maîtrisé.
Pourquoi une faille peut-elle rester cachée pendant des années ?
Un défaut ancien n'est pas forcément une faille « évidente ». Il peut rester dans le code sans être exploitable dans les conditions habituelles, ou sans que quelqu'un ait identifié comment le déclencher. Selon Schwartz, l'une des vulnérabilités discutées était présente depuis plus d'une décennie. Ce qui a changé n'est donc pas seulement le code : c'est la capacité à trouver une façon de l'exploiter.
Cette distinction évite une conclusion trop simple : « le logiciel est ancien, donc il est dangereux ». Oui, l'âge peut augmenter le risque, surtout quand la maintenance est faible. Mais un défaut, son exploitabilité et le niveau d'exposition d'un service sont des questions différentes.
Le contexte transforme un défaut en risque
Une vulnérabilité devient un problème opérationnel quand plusieurs conditions s'alignent : un composant vulnérable est présent, le chemin concerné est accessible, la configuration permet le comportement dangereux, et un attaquant peut atteindre la fonctionnalité en question. L'évaluation doit donc partir du système réel, pas uniquement du nom d'un logiciel dans un article.
C'est aussi la raison pour laquelle l'impact d'une même faille varie selon les organisations. Une version vulnérable sur un service public peut nécessiter une action immédiate. À l'inverse, un composant non utilisé ou isolé peut présenter un risque différent, sans pour autant être « à ignorer ». Le bon réflexe : vérifier les faits avant de se baser uniquement sur le niveau de gravité annoncé.
Le code ancien est souvent un problème de visibilité
Les applications accumulent des dépendances, des extensions et des versions maintenues par plusieurs équipes. Une entreprise peut connaître son application « principale » sans savoir précisément quel composant s'exécute sur chaque serveur. Ce manque de visibilité ralentit la réponse : avant de corriger, il faut souvent déterminer où se trouve exactement la version concernée.
La dette technique joue aussi. Un composant ancien peut être intégré à un système que personne ne maîtrise entièrement, notamment quand il s'agit des effets d'une mise à jour. Les équipes hésitent alors à corriger par crainte de casser une fonctionnalité ou une intégration. Cette prudence est compréhensible, mais elle doit être gérée : tester, prioriser et déployer de façon contrôlée vaut mieux que repousser indéfiniment.
La question ne se limite donc pas à : « avons-nous une faille ? ». Il faut aussi demander : sait-on où se trouve le code concerné, quelles conditions rendent le défaut exploitable, et combien de temps il faudra pour réduire le risque ?
Pourquoi la divulgation coordonnée est-elle si difficile ?
Quand une vulnérabilité touche un logiciel largement utilisé, plusieurs acteurs doivent se coordonner : les chercheurs qui l'ont découverte, les responsables du projet, les fournisseurs de services, et parfois des organisations qui dépendent du logiciel. Il faut valider le problème, préparer une correction, et donner aux utilisateurs assez d'informations pour agir sans faciliter inutilement l'exploitation.
Ce processus crée une tension. Prévenir trop tôt peut donner des indices à des attaquants avant que les correctifs existent. Attendre trop longtemps laisse les utilisateurs sans information alors que certains peuvent déjà être exposés. Dans l'épisode d'Equity, Schwartz explique que les fuites font presque partie du jeu dans la divulgation coordonnée. Son équipe avait donc envisagé ce scénario, plutôt que de croire que le secret tiendrait.
Une coordination ne veut pas dire une maîtrise totale
Même avec des échanges discrets, le nombre d'intervenants peut augmenter vite. Il faut préparer les versions corrigées, vérifier qu'elles fonctionnent, et informer des organisations situées dans différents fuseaux horaires. Et tous les systèmes vulnérables ne sont pas gérés par des équipes disponibles en permanence : certaines organisations découvrent le problème seulement au moment où il devient public.
C'est pourquoi une annonce ne se résume pas à « voici un correctif ». Il faut aussi préciser quelles versions sont touchées, quelles mesures temporaires sont raisonnables, et comment vérifier que la mise à jour a bien été appliquée. Une communication trop vague entretient la confusion ; une communication trop détaillée avant la mise en place de protections augmente le risque.
Préparer la réponse avant l'alerte
Une entreprise ne peut pas décider du calendrier d'une divulgation externe. En revanche, elle peut réduire le temps nécessaire pour comprendre et agir. L'idéal consiste à définir à l'avance qui reçoit les alertes, qui évalue l'exposition, qui valide une mise à jour urgente, et qui informe les clients si le service est concerné.
En crise, les décisions sont plus faciles quand les responsabilités sont claires. Qui peut isoler temporairement un composant ? Qui peut désactiver une fonctionnalité ? Qui peut mettre un service hors ligne ? Ces options ont un coût pour les utilisateurs et l'activité : elles ne doivent pas être improvisées au dernier moment.
Enfin, une divulgation coordonnée n'exonère personne. Les mainteneurs corrigent le logiciel, mais chaque entreprise reste responsable d'identifier ses propres systèmes et de choisir la manière de réduire son exposition.
Comment une startup peut-elle se préparer concrètement ?
Une jeune entreprise n'a pas besoin de reproduire l'organisation d'un grand groupe pour mieux gérer la sécurité. Elle a surtout besoin d'un processus proportionné, documenté, et réellement applicable. Le but n'est pas de garantir qu'il n'y aura jamais de vulnérabilité : c'est de réduire le temps entre l'annonce d'un problème et une décision bien maîtrisée.
1. Dresser un inventaire exploitable
Commencez par recenser les applications, services, versions de langages, dépendances et extensions réellement utilisés en production. L'inventaire doit avoir un responsable et permettre de répondre vite à une question simple : « Ce composant est-il chez nous, et où ? ». Une liste « théorique », jamais comparée aux déploiements réels, ne sert pas.
Pour une startup, l'inventaire peut être intégré au flux de livraison : registre des dépendances, contrôles automatisés dans les dépôts, et documentation des environnements. Priorité d'abord aux services exposés et aux composants dont la mise à jour est plus compliquée.
2. Définir une procédure de correction
Définissez des niveaux de priorité selon l'exposition, l'impact potentiel et la disponibilité d'un correctif. Une faille critique dans un composant accessible depuis Internet ne se traite pas comme une mise à jour mineure d'un outil interne isolé. Les délais de traitement peuvent aider, à condition d'être réalistes et d'être accompagnés d'exceptions documentées.
Visez un cycle court : confirmer les versions concernées, évaluer les systèmes exposés, tester le correctif, déployer, puis vérifier. Si vous ne pouvez pas corriger tout de suite, identifiez une mesure temporaire et fixez une date de réévaluation. « On verra plus tard » n'est pas une stratégie.
3. Tester la mise à jour sans retarder indéfiniment
Les correctifs peuvent introduire des régressions, surtout dans des applications anciennes ou très intégrées. Un environnement de préproduction et des tests ciblés réduisent le risque. Mais le contrôle ne doit pas devenir une excuse pour repousser toute correction. Le niveau de test doit être aligné sur le risque d'une panne et la gravité de l'exposition.
Documentez aussi les options de repli : retour à la version précédente, désactivation temporaire d'une fonctionnalité, ou isolement d'un service. Chaque option a des effets sur les utilisateurs, les opérations, et parfois sur des obligations contractuelles. Ces arbitrages doivent être connus avant l'incident.
4. Traiter les sites WordPress sans dramatiser
Un site WordPress n'est pas automatiquement vulnérable parce qu'une faille touche PHP. Le risque dépend notamment de la version de PHP utilisée par l'hébergeur, des composants installés, de leur configuration et du niveau d'exposition du site. Pour un propriétaire de petite entreprise, le bon point de départ consiste à vérifier ces éléments auprès de l'hébergeur ou du prestataire technique, puis à suivre les avis de sécurité pertinents.
Côté basique, il faut maintenir à jour le cœur, les thèmes et les extensions, supprimer ce qui n'est pas utilisé, et s'assurer qu'une sauvegarde récente peut être restaurée. Si l'hébergement est géré, demandez clairement qui applique les mises à jour du serveur et sous quels délais. Ces mesures ne garantissent pas l'absence de risque, mais elles évitent de dépendre d'une réaction improvisée.
Checklist de préparation : inventaire des composants, responsables nommés, procédure d'urgence, tests de mise à jour, sauvegardes restaurables et plan de communication. Si un de ces éléments manque, corrigez-le avant de chercher un « nouvel outil ».
Conclusion
L'IA rend certaines recherches de vulnérabilités plus rapides, mais elle ne supprime pas les difficultés de fond : comprendre ce qui tourne vraiment, coordonner la divulgation, et corriger sans casser l'activité. Le cas des failles PHP rappelle aussi une réalité simple : un défaut ancien peut devenir urgent quand de nouvelles méthodes permettent de le repérer plus vite.
Pour une entreprise, la préparation dépend moins d'un outil « spectaculaire » que de bases opérationnelles : connaître ses dépendances, attribuer les responsabilités, et être capable de tester puis déployer un correctif. La première étape, concrètement : vérifier aujourd'hui si votre équipe sait identifier les systèmes concernés par une alerte critique. Si cette réponse est floue, c'est là que commence l'amélioration.