Accès juste-à-temps : le privilège permanent est le chemin de la brèche

Ce que veut vraiment dire l’accès juste-à-temps

Dans la plupart des entreprises, l’essentiel des accès est permanent. Quelqu’un a eu besoin d’une permission une fois, un administrateur l’a accordée, et elle est restée. Personne n’a programmé son retrait, parce que le retrait n’a jamais fait partie de l’attribution. Trois ans plus tard, cette permission est toujours attachée au compte, toujours valide, et toujours invisible jusqu’à ce qu’un auditeur ou un attaquant la trouve.

L’accès juste-à-temps inverse le réglage par défaut. La permission est accordée pour un motif énoncé, pour une fenêtre bornée, et elle est reprise quand la fenêtre se referme. Palo Alto Networks décrit l’état d’arrivée, les privilèges permanents à zéro, comme « l’élimination de tous les droits d’accès permanents, pour chaque identité, humaine ou machine ». Le JIT est le mécanisme qui y mène : élever pour une tâche, pour une durée définie, puis redescendre.

L’idée n’est pas neuve. Ce qui a changé, c’est que le coût de l’accès permanent est devenu mesurable, et que le nombre d’identités qui en détiennent a cessé d’être à l’échelle humaine.

L’accès permanent, c’est là que la brèche se produit vraiment

Le rapport Verizon DBIR 2026 constate un vrai basculement à la porte d’entrée : 31% des violations démarrent désormais par une vulnérabilité logicielle, détrônant pour la première fois les identifiants volés comme premier vecteur d’accès initial. On pourrait y lire une bonne nouvelle pour les équipes identité. Ce n’en est pas une.

Les identifiants n’ont pas cessé de compter. Ils se sont déplacés. Comptés sur l’ensemble de la violation, et pas seulement sur la première étape, l’abus d’identifiants apparaît encore dans 39% des violations, et 73% des victimes de rançongiciel avaient connu une infection par infostealer ou une fuite d’identifiants dans l’année précédant l’attaque. L’exploit fait entrer l’attaquant. Ce sont les permissions permanentes attachées à l’identité sur laquelle il atterrit qui décident jusqu’où il ira.

Unit 42 mesure la même chose côté réponse à incident. Sur plus de 750 incidents majeurs traités entre octobre 2024 et septembre 2025, des faiblesses d’identité ont joué un rôle déterminant dans près de 90% des investigations, et 65% des accès initiaux reposaient sur des techniques fondées sur l’identité.

Voilà l’argument honnête en faveur du JIT, et il est plus étroit que ce que le marketing prétend d’ordinaire. Limiter les accès dans le temps n’arrêtera pas un hameçonnage et ne corrigera pas une faille. Ce que cela fait, c’est réduire le rayon d’action de chaque identifiant qui finira par fuiter, parce que la plupart des permissions dont un attaquant voudrait hériter n’existent plus au moment où il arrive.

Le nombre d’identités a cessé d’être à l’échelle humaine

Il y a une seconde raison à l’urgence de 2026. Le livre blanc de la Cloud Security Alliance sur les identités non humaines et la gouvernance de l’IA agentique le dit sans détour : comptes de service, clés d’API, jetons OAuth, certificats machine et identifiants maniés par les agents IA « dépassent désormais les utilisateurs humains dans un rapport moyen de 45 pour 1, et dans les environnements cloud-natifs ce rapport peut atteindre 144 pour 1 ».

D’autres estimations de 2026 vont encore plus haut. L’écart entre elles est en soi le constat. Personne n’a de décompte fiable, parce que la plupart de ces identités ont été créées par celui qui en avait besoin, dans l’outil qui en avait besoin, sans aucun cycle de vie attaché. Le même document rapporte que 78% des organisations n’ont aucune politique documentée pour créer ou retirer des identités d’IA, et que seulement 8% sont pleinement confiantes dans la capacité de leur IAM actuel à gérer le risque lié aux identités d’IA et non humaines.

La revue manuelle ne passe pas à cette échelle. Une campagne trimestrielle qui fonctionne raisonnablement pour 400 collaborateurs ne fonctionne pas pour 18 000 jetons, et encore moins pour un agent monté un mardi pour un flux de travail et jamais éteint. Nous avons traité la version structurelle de ce problème dans La faille de gouvernance de l’IA et Qu’est-ce que la couche d’accès pour les agents IA ?. En résumé : si un accès n’a pas d’expiration, il faut bien que quelque chose le retire, et à cette échelle ce quelque chose ne peut pas être une personne.

Pourquoi les projets JIT s’enlisent

Presque toutes les équipes sécurité adhèrent au principe. Beaucoup moins l’ont en production. Les échecs sont récurrents, et ce n’est pas une question d’adhésion.

Comment Lutril s’y prend

Dans Lutril, le JIT se configure par application, sur la page Politiques. Chaque politique vise un public, soit les collaborateurs, soit les agents IA, et peut être limitée à un niveau d’accès précis. Une politique écrite pour un niveau donné l’emporte sur le réglage par défaut de l’application, si bien que « Admin sur Notion » et « Membre sur Notion » peuvent se comporter très différemment.

Chaque public dispose de trois réglages : ce qui se passe à la demande, la durée maximale, et des conditions facultatives.

La durée est un plafond, pas une valeur figée

La durée maximale se règle en heures sur la politique. On demande au demandeur « De combien de temps avez-vous besoin ? » et il choisit dans une échelle de 1 heure, 4 heures, 8 heures, 1 jour, 3 jours ou 7 jours, filtrée par ce que la politique autorise. La même question s’affiche en menu déroulant dans Slack, en jeu de choix dans Teams, et en liste dans l’application Lutril.

Un approbateur peut raccourcir une attribution au moment de décider. Il ne peut pas l’allonger. La fenêtre effective est le plus petit des trois nombres en présence : le maximum de la politique, ce que le demandeur a demandé, et ce que l’approbateur a accordé. Aucun chemin dans le parcours ne produit un accès plus long que ce que la politique autorise.

Le compte à rebours démarre au moment de la décision, pas au dépôt de la demande. Si un approbateur met six heures à répondre, le demandeur dispose quand même de toute sa fenêtre.

Les conditions décident de qui saute la file

C’est la fatigue d’approbation qui tue les programmes JIT : la question intéressante n’est donc pas « qui a le droit » mais « qui ne devrait pas avoir besoin d’un humain ». L’éditeur de conditions pose exactement cette question, en une phrase : Accorder automatiquement quand. Vous construisez une règle, puis vous répondez à une seconde question sur tous ceux qui ne correspondent pas : un approbateur décide et l’accès expire quand même, ou un approbateur décide et l’accès n’expire jamais.

Les attributs résolus aujourd’hui incluent le service, l’intitulé de poste, le manager, le statut RH, l’état du MFA, interne ou externe, le statut dans l’IdP, les formations de sécurité en retard, le fait que la personne ait déjà accès à l’application, la sensibilité de l’application, et la demande elle-même : durée demandée, niveau d’accès et motif énoncé.

Tout attribut qui dépend d’une source que vous n’avez pas encore connectée est affiché comme indisponible, avec la raison écrite à côté. Vous ne construisez jamais une règle sur un signal qui n’arrivera pas, et vous savez toujours quelle connexion la débloquerait. Cela paraît anodin. C’est le troisième mode d’échec ci-dessus, refermé.

Les échecs se résolvent vers l’approbation, jamais vers le silence

Un moteur de politique qui ne parvient pas à résoudre un fait a trois options : autoriser, refuser, ou demander à un humain. Lutril demande toujours à un humain. Une condition non satisfaite ou invérifiable se dégrade en « approbation requise », jamais en attribution silencieuse ni en refus silencieux. Une règle de refus est évaluée avant le périmètre, si bien que resserrer une politique ne peut jamais l’assouplir par accident.

Au moment de la décision, les termes de la politique sont figés sur l’attribution. Modifier la politique demain ne réécrit pas ce qui a été autorisé aujourd’hui, et c’est ce qui rend le relevé utilisable comme preuve d’audit plutôt que comme instantané de la configuration courante.

Chaque expiration que Lutril fixe est une expiration qu’il peut honorer. La limitation dans le temps est câblée à un vrai chemin de retrait, que Lutril gère le compte via le provisionnement propre à l’application ou via les groupes Google Workspace et Microsoft Entra. L’échéance n’est pas un rappel dans l’agenda de quelqu’un. C’est le retrait.

Ce qui se passe à l’échéance

Une tâche de fond vérifie toutes les quelques minutes les attributions qui expirent et celles qui ont expiré. Trois choses peuvent survenir.

Un avertissement part d’abord. Le préavis est proportionnel à l’attribution, environ un quart de la fenêtre, plafonné à 24 heures. Une attribution de 7 jours est signalée un jour à l’avance. Une attribution d’1 heure n’est pas signalée du tout, parce qu’un avertissement sur une heure n’est que du bruit. Le message arrive dans Slack ou Teams, avec des boutons pour prolonger ou pour laisser expirer.

Les prolongations sont bornées. Une attribution peut être prolongée jusqu’à trois fois, et chaque prolongation est réévaluée contre la politique vivante, pas contre l’instantané figé. Si vous avez resserré la politique depuis l’attribution initiale, la prolongation respecte la nouvelle limite. Il n’y a pas de nouveau tour d’approbation, puisque l’approbateur avait déjà autorisé « jusqu’au maximum de la politique », et chaque prolongation est journalisée.

Le retrait passe d’abord par le déprovisionnement. L’accès est retiré à la source avant que l’attribution ne soit marquée comme expirée. Si le retrait échoue, l’attribution reste vivante et l’échec est journalisé pour le passage suivant. Un relevé qui affiche « expiré » alors que la permission est toujours attachée est pire que pas de relevé du tout.

Le même moteur, appliqué aux agents IA

Les politiques d’agents utilisent le même tableau, les mêmes conditions et la même logique de durée. Quatre choses diffèrent, et toutes les quatre existent parce qu’un agent n’est pas une personne.

• Le sujet est l’humain qui pilote l’agent. Le service, le statut RH et les conditions de formation s’évaluent contre cette personne, pas contre un compte de service sans attribut à évaluer.
• Un agent ne peut jamais dépasser les accès de son propriétaire. Cette vérification s’exécute avant même la consultation de la politique. Si le propriétaire n’a pas l’intégration, aucune politique ne peut la donner à l’agent.
• Lecture et écriture sont deux politiques distinctes. La portée est appariée exactement, si bien qu’une politique de lecture n’implique jamais l’écriture. Un agent qui peut fouiller votre CRM n’obtient pas pour autant le droit de le modifier.
• Les attributions à usage unique existent. Certains agents reçoivent une permission pour exactement un appel, consommée à la première utilisation réussie, avec une courte expiration de sécurité derrière au cas où l’appel n’arriverait jamais.

L’application se fait au niveau de l’appel d’outil, via le proxy MCP auquel l’agent se connecte. Si vous voulez la mécanique de cette couche, nous l’avons traitée dans La gouvernance MCP. Le point qui compte ici, c’est que limiter un agent dans le temps n’est pas un produit différent de limiter un collaborateur. C’est la même politique, avec le sujet remplacé.

Ce qu’il faut exiger de toute implémentation JIT

Que vous le construisiez ou l’achetiez, voici les propriétés qui séparent un JIT qui fonctionne d’une colonne « expiration » dans une base de données.

Le JIT ne réparera pas votre processus de départ à lui seul, et il ne remplace ni les revues d’accès ni un vrai traitement des départs. Ce qu’il fait, c’est changer le réglage par défaut. Un accès que personne n’a renouvelé cesse d’exister, sans que personne n’ait à penser à le retirer. À 45 identités non humaines par collaborateur, et ce chiffre grimpe, c’est la seule version du moindre privilège qui survive au contact du nombre réel d’identités que vous avez.