La maîtrise des identités devient une priorité d’architecture

Situation illustrative : un lundi matin, le RSSI apprend qu’un ancien prestataire peut encore administrer une application critique. Son contrat est terminé, son adresse nominative a disparu, mais un compte local subsiste derrière une passerelle d’accès distant. Au même moment, un robot d’intégration utilise un secret partagé que personne n’ose renouveler, de peur d’arrêter les échanges avec l’ERP. Le problème n’est pas seulement un défaut de sécurité. Il révèle une architecture incapable de relier chaque accès à un propriétaire, une finalité, une durée et une décision.

L’identité est devenue le point de passage du SI hybride

Dans un système d’information concentré dans quelques applications internes, le réseau pouvait encore jouer le rôle de frontière principale. Le cloud, les SaaS, le télétravail, les API et les partenaires ont déplacé cette frontière. Utilisateurs, administrateurs, applications, équipements et automatismes circulent désormais entre plusieurs environnements. Une identité compromise ou simplement oubliée peut donc ouvrir un chemin que les cloisonnements techniques ne suffisent plus à fermer.

Le mécanisme de risque est cumulatif. Une arrivée crée des droits ; une mobilité en ajoute ; un projet temporaire ouvre une exception ; un changement de fournisseur laisse un compte technique ; une réorganisation modifie les responsabilités sans corriger les habilitations. Chaque décision paraît localement raisonnable. Leur accumulation produit pourtant des privilèges sans justification actuelle, des comptes sans responsable et des dépendances impossibles à expliquer. L’architecture des identités doit précisément empêcher que l’histoire administrative de l’entreprise devienne sa surface d’attaque.

Le dirigeant doit d’abord choisir ce qu’il veut maîtriser

La première décision du DSI ou du RSSI n’est pas l’achat d’un outil. Elle consiste à fixer le périmètre de maîtrise. Faut-il commencer par les salariés, les comptes privilégiés, les prestataires, les identités applicatives ou les équipements ?

Le bon point de départ est le risque opérationnel. On identifie les processus dont l’interruption, l’altération ou la divulgation serait la plus grave, puis les ressources qui les supportent et les identités capables d’y agir. Un administrateur d’ERP, un compte de sauvegarde ou un robot de paiement ne se gouvernent pas comme l’accès d’un collaborateur à un outil de communication. Le niveau de contrôle doit suivre l’impact possible, non l’organigramme ni la commodité du catalogue logiciel.

Construire une chaîne de décision avant une chaîne d’outils

La démarche peut avancer par étapes. Premièrement, recenser les sources d’identité réellement utilisées : annuaire, applications locales, plateformes cloud, comptes techniques et accès de partenaires. Deuxièmement, attribuer à chaque identité sensible un propriétaire responsable de sa justification. Troisièmement, définir les événements qui déclenchent la création, la modification, la suspension et la suppression des droits. Quatrièmement, imposer une durée aux accès exceptionnels et privilégiés. Cinquièmement, organiser une revue fondée sur le risque plutôt qu’une certification massive et formelle.

Cette séquence impose des responsabilités claires. Les ressources humaines attestent certains événements concernant les salariés ; les métiers valident le besoin ; les responsables applicatifs décrivent les rôles ; l’IT exécute et trace ; le RSSI définit les exigences et contrôle les écarts. Pour l’acceptation d’un risque résiduel, un décideur unique doit être nommé. Sans cette répartition, l’automatisation accélère seulement des décisions mal définies.

Accepter les compromis sans accepter l’opacité

La maîtrise absolue n’existe pas. Une suppression immédiate peut interrompre une chaîne applicative ancienne. Une authentification renforcée peut être incompatible avec un équipement industriel. La séparation stricte des tâches peut devenir impraticable dans une petite équipe. Le dirigeant doit alors arbitrer entre continuité, sécurité, coût et vitesse, mais il ne doit pas laisser l’exception devenir invisible.

Toute dérogation devrait comporter un responsable, une justification, une échéance, une mesure compensatoire et une condition de sortie. Un compte partagé impossible à supprimer immédiatement peut, par exemple, être placé dans un coffre, limité à un usage précis, surveillé et assorti d’un plan de remplacement. C’est aussi une manière concrète de préserver la capacité interne à comprendre les accès critiques au lieu de la déléguer entièrement à un éditeur ou à un intégrateur.

Mesurer la réduction du risque, pas le volume d’administration

Le nombre de comptes créés ou de tickets fermés renseigne sur l’activité, pas sur la maîtrise. Des indicateurs plus utiles suivent le délai de révocation après un départ, la proportion d’identités sensibles avec un propriétaire, les privilèges sans date d’expiration, les comptes inactifs encore valides, les secrets non renouvelés, les revues en retard et les exceptions arrivées à échéance.

La qualité du contrôle se juge également lors d’un incident ou d’un audit interne. Peut-on établir rapidement qui disposait d’un droit, qui l’avait approuvé, quand il avait été utilisé et pourquoi il existait encore ? Si la réponse exige plusieurs jours de rapprochements manuels, l’organisation possède peut-être des outils, mais pas encore une architecture d’identité maîtrisée.

Éviter trois erreurs qui déplacent le problème

La première erreur consiste à confondre authentification forte et gouvernance. Vérifier solidement une personne ne dit pas si elle devrait disposer du droit demandé. La deuxième est de centraliser les comptes sans traiter les identités non humaines : API, robots, services et scripts deviennent alors l’angle mort du dispositif. La troisième est d’externaliser la complexité sans conserver la conception des rôles, la connaissance des processus critiques et la décision d’acceptation du risque.

L’arbitrage final porte donc sur l’architecture de responsabilité. Le DSI peut industrialiser les contrôles et confier certaines opérations, mais il doit garder en interne la capacité de définir les règles, d’identifier les dépendances et de contester les exceptions. Le RSSI, lui, doit pouvoir rendre les écarts visibles et audibles au bon niveau. C’est dans cette perspective que Révolution Numérique ! peut prolonger la réflexion : gouverner le numérique revient à relier technologie, risques, fournisseurs et décisions. La priorité n’est pas de promettre un accès sans friction ni un risque nul, mais de garantir qu’aucune identité critique ne demeure durablement sans propriétaire, sans raison et sans échéance.

Pour approfondir

Ouvrage : Révolution Numérique !: Le guide pour comprendre, décider et agir dans l’entreprise numérique — Amazon

Ouvrage : DSI EN CRISE: Reprendre le contrôle de l’IT, des ERP et des grands programmes — Amazon

Consulter la référence

Consulter la référence

#GouvernanceIT #ArchitectureSI #DSI #GuyDeLussigny #TransformationNumerique