Personne ne décide un matin de rendre son système d'information complexe. La complexité s'accumule, discrètement : une exception ici, un outil de plus là, une intégration temporaire qui devient permanente, un fournisseur ajouté sans en retirer un autre. Au bout de quelques années, plus personne ne sait dessiner l'architecture réelle sur un tableau blanc. C'est précisément à ce moment que la complexité cesse d'être un inconvénient pour devenir un risque de sécurité de premier ordre.
La règle est simple : vous ne pouvez pas sécuriser ce que vous ne comprenez pas. Et plus un système est complexe, moins il est compris — y compris par ceux qui l'ont construit.
La complexité est une surface d'attaque, pas un détail d'architecture
En cybersécurité, chaque composant supplémentaire n'ajoute pas un risque, il en ajoute plusieurs. Un nouvel outil, c'est un agent à maintenir à jour, des identifiants à gérer, une API à exposer, un fournisseur à surveiller, une intégration à tester. Le risque ne croît pas de façon linéaire avec le nombre de composants : il croît avec le nombre d'interactions entre eux, qui lui augmente de façon quasi exponentielle.
- Problème : chaque interconnexion est une porte. Plus il y en a, plus il devient impossible de toutes les verrouiller, ni même de toutes les recenser.
- Impact : les angles morts se multiplient. Le pare-feu mal configuré, le compte de service oublié, la règle de transfert d'e-mail laissée en place, l'instance cloud créée pour un test et jamais détruite — autant d'actifs que personne ne surveille parce que personne ne sait qu'ils existent.
- Action : traitez la réduction de complexité comme un contrôle de sécurité à part entière, au même titre que le chiffrement ou la MFA. Ce qui n'existe pas ne peut pas être attaqué.
Les attaquants l'ont parfaitement compris. Ils ne cherchent pas votre meilleure défense, ils cherchent votre composant le plus oublié. Les campagnes « living off the land » que nous avons décrites récemment exploitent exactement cela : des outils légitimes, déjà présents, noyés dans un environnement trop vaste pour être surveillé en entier.
Les vrais coûts de la complexité
La complexité ne se paie pas seulement le jour de l'incident. Elle prélève un impôt permanent, souvent invisible dans les budgets.
- Coût cognitif. Quand l'architecture dépasse ce qu'une équipe peut tenir en tête, les décisions se prennent sur des modèles mentaux faux. On corrige le mauvais composant, on duplique une fonction qui existe déjà, on suppose qu'un système est isolé alors qu'il ne l'est plus.
- Coût de détection. Plus il y a de signaux, de logs et d'alertes, plus le signal utile se noie dans le bruit. Un SOC qui reçoit 50 000 alertes par jour ne détecte pas mieux qu'un SOC qui en reçoit 500 ciblées : il détecte moins bien, parce que la fatigue d'alerte fait passer le vrai incident pour un faux positif de plus.
- Coût de réponse. En cas de crise, la complexité allonge chaque minute. Identifier les systèmes touchés, comprendre les dépendances, savoir ce qu'on peut couper sans tout casser : tout cela prend un temps que vous n'avez pas quand un rançongiciel chiffre vos sauvegardes.
- Coût de conformité. Vous ne pouvez pas attester d'un contrôle sur un périmètre que vous ne maîtrisez pas. Chaque exception, chaque système « spécial », chaque dérogation devient une ligne supplémentaire à documenter, à justifier et à défendre devant un auditeur.
- Coût humain. La complexité épuise les équipes. Les meilleurs ingénieurs partent quand ils passent plus de temps à comprendre l'existant qu'à construire. Et le départ d'une personne qui « était la seule à savoir » est, en soi, une vulnérabilité.
Pourquoi la complexité s'accumule (et pourquoi c'est si dur à inverser)
Comprendre le mécanisme aide à le combattre. La complexité prospère parce qu'ajouter est toujours plus facile que retirer.
Ajouter un outil résout un problème visible aujourd'hui. Retirer un outil exige de prouver qu'il n'est plus utile à personne — une charge de la preuve bien plus lourde, et un travail dont personne ne se voit récompensé. Résultat : on empile. Chaque acquisition, chaque réorganisation, chaque « solution rapide » dépose une couche que personne n'ose ensuite démanteler par peur de casser quelque chose d'invisible.
La complexité a aussi un biais politique : un système compliqué donne l'illusion de la robustesse et protège ceux qui en sont les seuls dépositaires. Simplifier demande donc du courage managérial autant que de la compétence technique.
Les bonnes pratiques pour désintoxiquer votre IT
Réduire la complexité n'est pas un projet ponctuel, c'est une discipline. Voici les pratiques qui font la différence.
Cartographiez avant de simplifier. On ne réduit pas ce qu'on ne voit pas. Établissez un inventaire réel et continu de vos actifs — exposés comme internes. Une démarche de gestion de la surface d'attaque externe (EASM) révèle souvent des dizaines de systèmes oubliés que vos schémas officiels ignoraient. La première victoire n'est pas de sécuriser ces actifs, c'est de découvrir qu'ils existent.
Adoptez le principe du « budget de complexité ». Comme la dette technique, la complexité doit avoir un plafond conscient. Imposez une règle simple : tout nouvel outil ou fournisseur ajouté doit s'accompagner de l'identification d'un composant à retirer, ou d'une justification explicite de pourquoi le solde augmente. Le but n'est pas zéro complexité — c'est la complexité choisie plutôt que subie.
Standardisez impitoyablement. Trois solutions qui font la même chose, ce sont trois fois la surface d'attaque, trois cycles de mise à jour, trois équipes à former. Convergez vers des standards : un fournisseur d'identité, un schéma de durcissement, un format de log, un processus de revue. La diversité accidentelle est une dette ; l'uniformité est un contrôle de sécurité.
Réduisez votre parc de fournisseurs. Chaque tiers est une extension de votre surface d'attaque que vous ne contrôlez pas directement — comme l'ont rappelé les brèches en cascade chez des prestataires partagés. Moins de fournisseurs, c'est moins de questionnaires, moins d'intégrations, moins de chaînes d'approvisionnement à surveiller. Rationalisez votre gestion du risque tiers en consolidant là où c'est possible et en supprimant les accès dormants.
Décommissionnez activement. Mettez en place un processus formel de fin de vie : quand un projet se termine, quand un employé part, quand un contrat expire, les actifs associés doivent être identifiés et détruits. Un actif sans propriétaire est un actif sans défenseur.
Privilégiez l'ennuyeux. En sécurité, la technologie « ennuyeuse », éprouvée et bien comprise bat presque toujours la nouveauté brillante. Chaque innovation que vous introduisez doit payer son coût de complexité par une valeur clairement supérieure. La question n'est pas « est-ce que ce nouvel outil est meilleur ? » mais « est-ce qu'il est suffisamment meilleur pour justifier la surface qu'il ajoute ? »
Mesurez la complexité, sinon elle redevient invisible. Suivez quelques indicateurs : nombre d'actifs exposés, nombre de fournisseurs avec accès aux données, nombre d'exceptions de sécurité ouvertes, âge médian des systèmes non patchés. Ce qui n'est pas mesuré dérive toujours vers le haut.
La simplicité est une décision stratégique
La simplicité ne s'obtient pas par accident. C'est le résultat d'arbitrages constants, souvent inconfortables, où l'on refuse l'ajout facile au profit de la clarté durable. C'est une responsabilité de direction autant que d'ingénierie : un comité de direction qui exige de la visibilité, des métriques de risque et une priorisation claire crée les conditions pour que les équipes osent simplifier.
La complexité est le terrain de jeu de l'attaquant. La clarté est votre avantage défensif. Réduire la première, c'est augmenter la seconde — et c'est, concrètement, l'une des décisions de sécurité les plus rentables que vous puissiez prendre.
Si vous voulez voir à quoi ressemble cette clarté — une surface d'attaque cartographiée, des risques priorisés, des fournisseurs sous contrôle dans une seule vue — le tour du produit montre comment nous transformons l'exposition en actions priorisées.