Il n’existe pas d’outil qui ne tombera jamais. Il n’existe que des organisations qui ont préparé le jour où il tombe, et les autres. Octobre 2026 vient de me le rappeler deux fois en six jours, et je préfère l’écrire à la première personne, parce que c’est une conviction avant d’être une méthode.
Deux matins d’octobre
Le jeudi 15 octobre, entre 6 h 13 et 8 h 34 UTC, quelqu’un a parcouru près d’un millier de tenants Microsoft 365 à quelques secondes d’intervalle, avec un identifiant volé à une application de sauvegarde très répandue chez les prestataires informatiques, ConnectWise Cloud Backup, l’ancien SkyKick (SpecterOps). Pas un mot de passe d’utilisateur : l’identifiant de l’application elle-même, celui qui ouvre chaque tenant où elle a été consentie. Environ 300 connexions ont réussi. Dans au moins un tenant, une seconde application du même éditeur s’est attribué le rôle d’administrateur général et a déposé des secrets dans deux autres applications, pour pouvoir revenir une fois le premier identifiant révoqué. L’éditeur a coupé son service le 17, puis révoqué ses certificats ; les sauvegardes de ses clients sont inaccessibles « jusqu’à nouvel ordre » (iTnews). Au moment où j’écris, personne ne sait comment l’identifiant a été volé.
Le mercredi 21 octobre à 16 h, heure de Paris, PHP publiait quatre correctifs pour deux failles notées 9,2 sur 10, exécution de code à distance sans authentification, sur un langage qui fait tourner 69,3 % des sites dont on connaît le langage serveur (CERT-FR, alerte 2026-ALE-014). La divulgation avait été avancée parce que l’information fuyait. Dès midi et demi, la CNIL affichait une page de maintenance. Le ministère de l’Intérieur mettait hors ligne les sites de plusieurs préfectures, le temps d’appliquer les mesures. Aux Pays-Bas, le parlement et le centre national de cybersécurité faisaient de même. Aucun de ces sites n’a été piraté. Ils ont été coupés avant.
Rien de tout cela ne nous a touchés directement : notre site est statique, sans PHP, et nous n’utilisons pas ce service de sauvegarde. Je n’écris donc pas pour nous défendre. J’écris parce que les deux affaires racontent la même chose, et que cette chose concerne tout le monde.
Pourquoi j’ai cessé de poser la question « si »
Personne n’a été imprudent. PHP tenait depuis trente ans. L’application de sauvegarde était consentie par des milliers d’entreprises sérieuses, conseillées par des prestataires sérieux. Dans les deux cas, chacun a choisi l’outil que tout le monde choisit, parce qu’il est pratique, éprouvé, diffusé. Et c’est précisément ce choix collectif qui a transformé une faille en événement mondial le même matin : plus un outil est répandu, plus il rend service à tous et plus il devient le point unique de défaillance de tous.
J’ai longtemps raisonné comme la plupart des gens de mon métier. On évaluait un outil, on se demandait s’il était sûr, on concluait que oui, et on passait à autre chose. Je ne pose plus cette question. Tout outil tombera. L’identifiant sera volé, la faille sera trouvée, l’éditeur sera racheté, le service sera coupé un vendredi. La seule inconnue est la date.
Le jour où l’on admet cela, on cesse de choisir des outils et on se met à choisir des délais. Combien de temps avant que je le sache. Combien de temps pour couper. Combien de jours je tiens sans lui. Trois durées, et une organisation se juge sur ces trois durées bien plus que sur la liste de ses produits.
Ce que les préfectures et la CNIL ont bien fait
On a souri, le 21 octobre, devant ces pages de maintenance qui fleurissaient sur les sites publics. J’y ai vu autre chose. Couper avant toute preuve d’attaque, sur la seule foi d’un bulletin, c’est la réponse d’une organisation qui a préparé le « quand » : quelqu’un savait quels sites tournaient sous PHP, quelqu’un avait le droit de les éteindre, quelqu’un savait ce que ça coûtait de les éteindre et a jugé que c’était moins cher que l’alternative. Une page de maintenance à midi et demi, le jour même, vaut mieux qu’un communiqué de compromission trois semaines plus tard.
Le CERT-FR dispose de preuves de concept pour les deux failles et ne signale pas, à ce jour, d’exploitation massive. Certains en concluent que la coupure était excessive. Je crois l’inverse : la décision était bonne au moment où elle a été prise, avec l’information disponible, et c’est le seul critère honnête pour juger une décision de résilience. Un prestataire qui se moque d’une page de maintenance n’a jamais eu à en poser une.
Les trois questions que je pose maintenant avant tout choix technique
Je les applique à un langage de site, à une application consentie dans un tenant, à un prestataire, et à nous-mêmes, puisque nous sommes le prestataire de nos clients.
Première question : en combien de temps je saurai. Pas « serai-je prévenu », mais par quel chemin et en combien d’heures. Dans l’affaire de la sauvegarde, c’est un éditeur de sécurité tiers qui a donné l’alerte, le 16 octobre, pas l’éditeur du service, qui n’a pas de visibilité dans les tenants de ses clients et le dit lui-même. Si votre seule source d’alerte est le fournisseur concerné, votre délai pour savoir dépend de son intérêt à parler.
Deuxième question : en combien de temps je coupe, et comment je le prouve. Un consentement d’application se désactive en dix minutes dans le centre d’administration Entra, à condition de savoir qu’il existe, de savoir qui a le droit de le faire, et d’avoir accepté d’avance que le service s’arrête. Les jetons déjà émis restent valides jusqu’à 90 minutes après la coupure : même l’arrêt a un délai, et il faut le connaître avant d’en avoir besoin. La preuve, c’est le journal de connexion des principaux de service et la liste des identifiants ajoutés depuis une date : ce que nous demandons à nos clients de pouvoir produire, nous devons pouvoir le produire sur nos propres outils.
Troisième question : combien de jours je tiens sans lui. Les clients de ce service de sauvegarde ne peuvent rien restaurer depuis le 17 octobre. Les préfectures ont tenu sans leurs sites. Une entreprise doit savoir, pour chaque brique, ce qui se passe quand elle disparaît un matin sans préavis, et pendant combien de jours c’est supportable. Notre calculateur du coût d’un arrêt informatique donne l’ordre de grandeur en une minute ; la stratégie de sortie que DORA exige des acteurs régulés n’est rien d’autre que cette troisième question, écrite et testée.
Une objection que j’entends souvent : « à ce compte-là, on ne connecte plus rien ». Non, on connecte en connaissance de cause. L’application de sauvegarde demandait un droit d’écriture sur tout l’annuaire pour faire des sauvegardes. Personne n’avait relu cette ligne depuis le consentement initial. La question n’est pas de refuser le tiers, c’est de relire ce qu’on lui a donné, à date fixe, comme un contrat à durée déterminée.
Ce que je m’engage à faire
Je n’ai pas de leçon à donner, j’ai des choix à annoncer, puisque c’est ce qui se vérifie.
D’abord, publier nos délais mesurés plutôt que des promesses. Nous l’avons commencé la semaine dernière sur la page Transparence : le temps que met notre protection des postes à bloquer une menace, le temps que met notre surveillance à confiner et à nous prévenir, calculés sur trois mois de données réelles, recalculés chaque trimestre. La prochaine durée à publier est celle de la deuxième question : le temps qu’il nous faut pour révoquer un accès tiers dans un tenant client, mesuré lors d’un exercice, pas estimé.
Ensuite, traiter chaque consentement d’application comme un engagement à durée déterminée. Chaque application tierce présente dans les tenants que nous gérons, les nôtres comprises, aura une date de revue, une liste de droits justifiés ligne à ligne et une procédure de coupure écrite, avec le nom de la personne qui a le droit de l’exécuter sans demander. C’est le prolongement de ce que nous écrivions sur la chaîne des prestataires : remonter la chaîne ne sert à rien si l’on ne sait pas la couper.
Enfin, concevoir chaque brique de notre socle en se demandant comment on la retire. Avant d’ajouter un outil, nous décrirons le matin où il disparaît : ce qui s’arrête, ce qui continue, qui est prévenu, ce que nous disons au client à 9 h. Un outil dont nous ne savons pas écrire ce paragraphe n’entre pas.
Je pense à l’avenir en écrivant cela. Les agents d’intelligence artificielle que l’on branche aujourd’hui sur les messageries, les documents et les annuaires sont des applications consenties, avec des droits larges, chez des éditeurs jeunes. Ils rendront d’immenses services et ils tomberont, comme PHP et comme cette sauvegarde, et la même question les attend. Nous les déployons déjà, chez nous, avec les trois questions posées avant le premier consentement ; nous les déploierons chez nos clients de la même façon, ou pas du tout. La compromission par device code que nous avons reconstituée il y a quinze jours montrait déjà qu’un compte ordinaire suffit ; une application consentie n’a même pas besoin de compte.
Reste la question que je vous laisse. Prenez l’outil dont vous ne pourriez pas vous passer une semaine, celui auquel vous ne pensez plus tellement il marche. Savez-vous ce que vous feriez s’il tombait mercredi à 16 h ?
Si vous voulez y répondre à deux, Marin ou moi vous recevons trente minutes, sur rendez-vous, et l’état des lieux initial est offert.
Gregory Moulis, directeur général d’ITAIA
Sources
- CERT-FR, Alerte CERTFR-2026-ALE-014 : multiples vulnérabilités dans PHP, publiée le 21 octobre 2026 et mise à jour le 22 : CVE-2026-109618 et CVE-2026-109619, versions corrigées, preuves de concept, recommandation d’isoler et de migrer.
- SpecterOps, ConnectWise SkyKick Breach: How to Check Your Microsoft 365 Tenant, 17 octobre 2026 : horaires du 15 octobre, mécanisme de l’identifiant d’application, rôle d’administrateur général ajouté, validité résiduelle des jetons, vérifications recommandées.
- iTnews, Stolen ConnectWise ‘SkyKick’ credential exposed Microsoft 365 tenants, 18 octobre 2026 : nombre de tenants, déclarations de l’éditeur, coupure du service.
- Selectra, Failles PHP : les sites coupés le 21 octobre : CNIL, préfectures, parlement néerlandais, part de PHP dans le web selon W3Techs.