Les tendances annoncées chaque année tiennent rarement leurs promesses. Celles qui suivent ont un point commun : elles ont déjà changé le quotidien des équipes, avant même d'être devenues des sujets de conférence.
1. L'identité des machines dépasse celle des humains
Dans une entreprise moderne, les comptes de service, jetons d'API, clés d'intégration et identités d'agents automatisés dépassent largement le nombre d'employés — souvent d'un facteur dix ou plus. Ces identités-là n'ont ni deuxième facteur, ni formation à l'hameçonnage, ni départ de l'entreprise qui déclenche leur désactivation.
Le résultat est prévisible : un jeton créé pour une intégration temporaire, oublié dans un dépôt de code ou un fichier de configuration, valable indéfiniment, avec des droits bien plus larges que nécessaire. C'est aujourd'hui l'un des chemins d'intrusion les plus rentables.
Ce qui change concrètement : l'inventaire des identités non humaines devient un livrable à part entière, la rotation des secrets devient automatique, et les droits d'un compte de service sont réduits au strict nécessaire — un travail fastidieux que personne ne veut faire et que tout le monde regrette de ne pas avoir fait.
2. La chaîne d'approvisionnement logicielle devient un périmètre à part entière
Une application moderne, c'est quelques milliers de lignes écrites en interne et quelques centaines de milliers importées : bibliothèques, images de conteneurs, extensions, actions d'intégration continue. Chacune est un point d'entrée, et la plupart sont mises à jour automatiquement.
Les attaques les plus marquantes de ces dernières années n'ont pas visé les entreprises directement : elles ont visé un fournisseur, un paquet populaire, un outil de build. Le rapport coût-bénéfice pour l'attaquant est imbattable.
Ce qui change : la nomenclature logicielle — savoir ce que contient réellement ce qu'on déploie — passe du statut de bonne pratique à celui d'exigence contractuelle, en particulier dans les secteurs régulés. Et la question posée aux fournisseurs cesse d'être « êtes-vous certifiés ? » pour devenir « que se passe-t-il chez vous quand une faille critique est publiée un vendredi soir ? ».
3. L'IA joue des deux côtés, et pas symétriquement
Côté attaquant, le gain est immédiat et sans effort d'adaptation : des messages d'hameçonnage sans faute de français, personnalisés à partir de sources publiques, produits en masse. Le repère « le message est mal écrit, donc c'est une arnaque » — sur lequel reposait une bonne partie de la sensibilisation — ne fonctionne plus. L'imitation vocale rend par ailleurs la vérification par téléphone beaucoup moins fiable qu'on ne le croit.
Côté défense, le gain existe mais demande du travail : tri des alertes, corrélation, aide à l'investigation. Utile, sans rien de magique.
Le sujet vraiment nouveau, c'est l'IA comme surface d'attaque. Un assistant branché sur vos données internes est un système qui lit du contenu non fiable et agit ensuite. L'injection d'instructions dans un document, un e-mail ou une page web devient un vecteur crédible, et la plupart des déploiements se font sans avoir posé la question : que peut faire cet assistant, avec les droits de qui, et sur la base de quel contenu ?
4. La réglementation change de nature
Les textes récents partagent une orientation : ils ne demandent plus des mesures, ils demandent des résultats démontrables. Gouvernance identifiée, incidents déclarés dans des délais courts, fournisseurs critiques maîtrisés, dirigeants responsables.
Deux conséquences pratiques. La première : la sécurité de vos fournisseurs devient votre problème, contractuellement. La seconde : le délai de déclaration d'incident se compte désormais en heures, ce qui suppose d'avoir décidé à l'avance qui qualifie un incident, qui déclare et à qui. Une organisation qui découvre ces questions pendant l'incident ne tiendra pas le délai.
Les échéances et périmètres exacts dépendent de votre secteur et de votre taille : à vérifier auprès de votre conseil, ces textes évoluent vite.
5. Le facteur humain revient, autrement
La sensibilisation classique — module annuel, faux hameçonnage, taux de clic — a atteint ses limites. Elle mesure surtout la capacité à reconnaître un exercice.
Ce qui fonctionne mieux relève de la conception plutôt que de la formation : rendre l'action sûre plus simple que l'action risquée, supprimer les situations où quelqu'un doit juger seul de la légitimité d'une demande urgente, et instaurer des procédures de vérification qui ne reposent pas sur la reconnaissance d'une voix ou d'un style d'écriture.
Le vrai indicateur n'est pas le taux de clic : c'est le délai entre l'erreur et son signalement. Une organisation où l'on ose dire « je crois que j'ai cliqué » se remet d'un incident. Une organisation où l'on a peur de le dire le découvre trois semaines plus tard.
Ce que ça implique pour les profils
Ces cinq déplacements ont un point commun : ils demandent moins d'expertise sur un produit et davantage de capacité à arbitrer et à faire appliquer. Les profils qui montent sont ceux qui savent tenir une conversation d'architecture avec une équipe technique le matin et expliquer un risque résiduel à un comité de direction l'après-midi.
Vous cherchez ce type de profil, ou vous en êtes un ? Voyez les missions ouvertes, les profils disponibles, ou notre article sur le RSSI à temps partagé.