Trois failles cotées 10 sur 10 chez ServiceNow exposent « l'effet d'amplification » des agents IA à large accès — l'argument structurel qu'AppH tire de sa propre porte d'approbation humaine
Le 28 août 2026, Forkast.News a détaillé trois vulnérabilités notées CVSS 10.0 — le score maximal — dans la couche d'orchestration d'agents IA de la plateforme ServiceNow, une brèche d'injection de code dans un système qui conserve le contexte de session, les identifiants et la configuration des outils que les agents utilisent pour agir au nom des utilisateurs. AppH n'a ni la même architecture ni la même surface d'attaque que ServiceNow — mais l'article nomme précisément le risque que la porte d'approbation humaine d'AppH existe pour bloquer : un agent à large accès qui peut lire, écrire et exécuter sans qu'un humain n'intervienne.
Le 28 août 2026, Forkast.News a publié une analyse détaillant trois vulnérabilités notées CVSS 10.0 — le score maximal sur l'échelle de gravité des failles logicielles — découvertes dans la couche d'orchestration d'agents IA de la plateforme ServiceNow. Les failles permettent une injection de code dans un système qui héberge le contexte de session, les identifiants et la configuration des outils que les agents IA utilisent pour agir au nom des utilisateurs de l'entreprise. L'article nomme explicitement ce qu'il appelle « l'effet d'amplification des agents » (agent amplification effect) : des agents dotés d'un accès large — lire et écrire des enregistrements, déclencher des workflows, escalader des tickets, exécuter des scripts — transforment un bug ordinaire d'injection de code en incident à bien plus grande échelle, parce que l'agent compromis hérite de tous les privilèges qu'on lui a donnés.
AppH n'est pas ServiceNow et ne partage ni son architecture ni sa surface d'attaque — présenter cet incident comme une comparaison directe des deux plateformes serait inexact, et ce n'est pas ce que cet article affirme. Le point réel et légitime à en tirer est structurel, pas concurrentiel : l'architecture d'AppH — un agent scopé par compte, et surtout une approbation humaine obligatoire avant toute action à conséquence réelle (envoyer un message, facturer un client, annuler une réservation) — limite déjà précisément ce que l'article appelle l'effet d'amplification, parce que même un agent compromis ou défaillant ne peut pas exécuter une action métier réelle sans franchir cette porte de validation humaine. Ce n'est pas un slogan marketing, c'est un choix d'architecture vérifiable dans chaque module. Et ça vaut au-delà d'AppH : n'importe quel utilisateur d'une plateforme d'orchestration d'agents — AppH comprise — devrait vérifier périodiquement qu'aucun endpoint interne ne combine lecture, écriture et exécution sans porte de validation, exactement le schéma de risque que cet article documente.
Pour AppH
- L'incident ServiceNow donne un nom précis et un exemple daté, chiffré au score de gravité maximal, à un risque qu'AppH décrit depuis toujours en interne sans jamais avoir eu de cas concret aussi net à citer : un agent à large accès sans porte de validation transforme n'importe quelle faille, même mineure, en incident à grande échelle. C'est un argument concret à présenter à un client qui se demande pourquoi AppH impose un clic humain avant chaque action à conséquence réelle plutôt que de vanter une automatisation totale.
- L'architecture d'AppH — approbation humaine obligatoire avant toute action métier — répond directement au schéma de risque nommé par l'article (lecture + écriture + exécution sans contrôle), sans qu'aucune réglementation ni aucun incident n'ait eu à l'imposer après coup : c'est une garantie structurelle intégrée dès la conception, pas un correctif ajouté après une faille.
Contre / la limite honnête
- Un score CVSS de 10 sur 10 mesure la gravité et la facilité d'exploitation d'une faille, pas la probabilité qu'elle survienne réellement chez un fournisseur donné, AppH inclus. Présenter cet incident comme une preuve qu'AppH a été auditée contre cette classe précise de vulnérabilité serait inexact — c'est un argument de gouvernance et d'architecture, pas le résultat d'un audit de sécurité mené sur AppH elle-même.
- ServiceNow et AppH n'opèrent pas à la même échelle ni sur la même surface technique — une plateforme d'entreprise avec des milliers d'intégrations tierces expose mécaniquement plus de points d'entrée qu'un produit vertical pour PME. Prétendre que les deux plateformes courent exactement le même risque reviendrait à ignorer cette différence d'échelle réelle.
Ce qui frappe dans cet incident n'est pas le chiffre 10 sur 10 en lui-même — les échelles de gravité existent justement pour signaler qu'une poignée de failles méritent l'attention immédiate de tout le monde, pas seulement des clients de ServiceNow. Ce qui frappe, c'est que la faille touche exactement la couche que toute plateforme d'agents IA, AppH comprise, doit prendre au sérieux en priorité : celle qui décide ce qu'un agent a le droit de faire, et avec quels identifiants. Accompagner un dirigeant de PME sur ce sujet, ce n'est pas lui dire qu'AppH est invulnérable — aucune plateforme ne peut l'affirmer honnêtement — c'est lui expliquer pourquoi la question à poser n'est jamais « est-ce que votre IA peut tout faire vite » mais « qu'est-ce qui empêche un agent compromis ou qui se trompe d'exécuter une action réelle sans qu'un humain ne l'ait vue d'abord ». Chez AppH, la réponse reste la même depuis le premier module : rien ne part, rien ne se facture, rien ne s'annule sans qu'un humain de l'entreprise ait cliqué en premier — et nous recommandons à quiconque évalue une plateforme d'agents IA, la nôtre incluse, de vérifier concrètement que cette porte existe avant de lui confier des données réelles.
Vérifié par un humain d'AppH