# Provisionnement réversible des utilisateurs SaaS par les agents IA

Un agent IA ne devrait jamais provisionner un utilisateur SaaS à partir d'une consigne opaque comme « ajoute Priya au compte de l'entreprise avec les accès habituels de l'équipe technique ». Cette phrase masque au moins trois changements d'état : créer ou inviter une identité, attribuer un rôle au niveau du compte et ajouter des appartenances à des groupes. Chacun présente un risque, une condition d'achèvement et une opération d'annulation différents.

Le provisionnement réversible des utilisateurs SaaS commence par le respect de ces frontières. L'agent propose une séquence, exécute un appel à la fois, conserve les identifiants renvoyés et s'arrête dès que l'état observé diffère de l'état attendu. Quelques appels d'API supplémentaires évitent à l'opérateur de reconstituer une attribution d'accès incomplète après une expiration de délai, une mauvaise adresse ou un groupe trop permissif.

## Invitation, rôle et appartenance sont des états distincts

Une invitation en attente n'est pas un utilisateur, un utilisateur n'est pas un rôle et un rôle n'est pas une appartenance à un groupe. Les systèmes de provisionnement confondent souvent ces objets parce que les consoles les regroupent dans un même formulaire. L'API sous-jacente expose pourtant fréquemment des ressources ou des opérations de cycle de vie différentes, ce qui décide si l'agent peut reprendre proprement.

Une invitation représente généralement une intention assortie d'un processus d'envoi ou d'acceptation. Le destinataire peut devoir l'accepter, employer une autre identité ou ne jamais répondre. Microsoft Graph le précise pour les utilisateurs externes : la création renvoie un objet d'invitation, puis la personne accomplit un parcours interactif. Chez GitHub, l'appartenance à une organisation reste également en attente jusqu'à l'acceptation. Un agent qui inscrit « utilisateur créé » juste après l'invitation consigne un souhait, pas un fait.

Un rôle modifie l'autorité dans le compte ou l'organisation. Il peut faire d'une personne un propriétaire, un responsable de facturation, un administrateur, un invité ou un membre ordinaire. Un groupe donne souvent un accès indirect à des projets, dépôts, canaux, applications ou données partagées. Retirer le groupe peut supprimer cet accès sans modifier le rôle du compte, tandis qu'une rétrogradation peut laisser les droits issus des groupes intacts.

Modélisez les états séparément, même si le fournisseur propose un endpoint pratique qui accepte les trois dans un seul POST. Un enregistrement interne raisonnable ressemble à ceci :

```json
{
  "subject": "priya@example.test",
  "invitation": {"state": "pending", "id": "inv_8421"},
  "role": {"desired": "member", "observed": null},
  "groups": {
    "desired": ["engineering", "on-call-readers"],
    "observed": []
  }
}
```

Cette séparation répond à la question opérationnelle délicate : que faut-il annuler exactement ? Si l'invitation existe sans compte accepté, annulez-la. Si le compte possède le mauvais rôle, restaurez le précédent. Si un groupe a été ajouté avant l'échec du suivant, retirez uniquement l'appartenance créée pendant cette exécution. Supprimer tout l'utilisateur remplace généralement la connaissance de l'état par une action téméraire.

La première règle de conception est donc simple : une action journalisée doit correspondre à une transition d'état observable à distance. L'appel peut encore provoquer un effet annexe, tel qu'un courriel, mais l'agent et l'opérateur doivent pouvoir nommer la transition principale sans ajouter « et il a aussi… ».

## Le plan de provisionnement doit être une donnée

L'agent doit compiler la demande humaine en un plan typé avant d'appeler le fournisseur. Le plan rend visibles les hypothèses ambiguës et fournit des entrées stables à l'exécuteur. Le raisonnement libre a sa place avant l'exécution ; sa frontière doit recevoir des données ordinaires et précises.

Le plan comprend au minimum l'identifiant du sujet, le tenant cible, le mode d'invitation, le rôle et les groupes demandés, les préconditions et l'identifiant d'opération. Il doit aussi indiquer si un courriel peut partir. Cet envoi est un effet externe qu'une annulation ne peut rappeler ; le cacher derrière une valeur par défaut est une mauvaise pratique.

```json
{
  "operation_id": "prov_2026_07_24_0187",
  "tenant": "acme-production",
  "subject": {"email": "priya@example.test"},
  "steps": [
    {"kind": "invite", "send_email": false},
    {"kind": "wait_for_acceptance"},
    {"kind": "set_role", "role": "member"},
    {"kind": "add_group", "group": "engineering"},
    {"kind": "add_group", "group": "on-call-readers"}
  ],
  "preconditions": {
    "account_absent": true,
    "allowed_email_domain": "example.test"
  }
}
```

Gardez chaque ajout de groupe dans une étape distincte au lieu de transmettre une liste à un endpoint général. L'exécuteur peut alors approuver, reprendre et compenser chaque appartenance indépendamment. Le plan révèle aussi l'ordre. Si le rôle ne peut être attribué avant l'acceptation, `wait_for_acceptance` est une vraie barrière d'état, pas une instruction de temporisation.

Validez le plan avec des contraintes locales avant d'exposer un secret ou d'émettre un appel réseau. Vérifiez que le tenant est un identifiant exact et connu, normalisez le domaine du courriel sans modifier sa partie locale, résolvez les noms de groupes en identifiants immuables du fournisseur et refusez les rôles de propriétaire ou d'administrateur sauf demande explicite. L'agent ne doit pas rechercher un tenant parmi tous les comptes accessibles à un jeton puissant.

Les lectures préalables doivent capturer l'état existant. Cherchez le sujet avec l'attribut unique documenté, puis lisez directement son rôle et ses appartenances. Distinguez « absent » de « lecture impossible ». Un 403, un délai dépassé ou une page tronquée ne prouvent pas l'absence. Si la recherche est paginée ou à cohérence éventuelle, consignez cette limite et imposez une lecture plus forte avant toute création.

Après approbation, figez le plan. Tout changement d'adresse, de rôle, d'identifiant de groupe ou d'option d'envoi doit produire un nouvel identifiant d'opération et une nouvelle décision. Sinon, la phrase approuvée et les appels réels peuvent diverger en silence.

## Préparez l'invitation avant de donner l'accès

Créez ou envoyez d'abord l'invitation, puis arrêtez-vous jusqu'à ce que le service prouve ce qui s'est passé. N'y regroupez pas des rôles privilégiés et des groupes sensibles uniquement parce que l'endpoint l'autorise. Le regroupement paraît efficace : une requête semble atomique et produit une notification. En pratique, la plupart des API SaaS ne garantissent aucune transaction couvrant identité, rôle, notification et propagation des groupes.

L'endpoint d'invitation aux organisations GitHub illustre la tentation. Une requête peut inclure un rôle et des identifiants d'équipe. C'est commode dans une console, mais l'exécuteur autonome perd des points de contrôle en envoyant tout ensemble. Une erreur de validation peut tout refuser ; une réponse perdue après traitement le laisse ignorer quels effets ont eu lieu. Une acceptation humaine tardive peut aussi activer des accès après la fin de l'exécution.

Préférez l'invitation la moins puissante permise. Si elle doit porter un rôle, utilisez celui de membre ordinaire et reportez l'élévation. Si elle exige un groupe ou un canal, choisissez un espace d'accueil sans ressource sensible, puis ajoutez les appartenances prévues lorsque l'identité atteint le bon état. Certaines API imposent des contraintes. La méthode Enterprise Grid de Slack exige par exemple au moins un identifiant de canal : il faut donc définir un canal d'arrivée peu privilégié, pas joindre tous les canaux de travail au premier appel.

Consignez l'envoi éventuel du courriel et conservez l'identifiant, le statut, l'heure de création et le sujet canonique renvoyés. N'enregistrez pas une URL d'acceptation dans un journal largement accessible, car elle peut agir comme une capacité au porteur. Si l'API en renvoie une pour une livraison séparée, faites-la passer par le plus petit composant de confiance et masquez-la à l'agent.

Une invitation préparée a besoin d'une condition terminale explicite. Utilisez `accepted`, `expired`, `cancelled` et `pending` lorsque le fournisseur les expose. Sinon, déduisez l'état des champs documentés et marquez-le comme dérivé. « Le POST a renvoyé 201 » ne signifie jamais « le destinataire peut accéder aux données de production ».

Fixez une échéance dans l'opération locale. Lorsqu'elle expire, lisez l'état, puis annulez l'invitation encore en attente si la demande n'est plus valable. N'exécutez pas d'annulation aveugle : la personne peut avoir accepté juste avant le déclenchement. Il faut lire, comparer, puis agir.

L'annulation n'est réversible qu'au sens étroit. Elle empêche une acceptation ultérieure si le service le permet, mais ne rappelle pas le courriel et n'efface pas la connaissance de l'organisation. Écrivez cette limite sur la carte d'approbation. Le mot « réversible » doit décrire l'autorisation distante, pas prétendre supprimer toutes les conséquences.

## Attribuez le rôle après stabilisation de l'identité

Attendez de pouvoir lier la demande à un identifiant distant stable. Une adresse aide à chercher, mais constitue un mauvais identifiant durable : elle change, les alias se heurtent et un invité peut accepter avec un compte existant. Les appels suivants doivent viser l'identifiant utilisateur renvoyé par le fournisseur.

Avant de modifier le rôle, lisez la valeur actuelle et conservez-la pour la compensation. Si elle correspond déjà à la valeur voulue, enregistrez une absence de changement au lieu d'écrire encore. Cette trace prouve que l'exécuteur a vérifié la condition sans s'attribuer une modification effectuée par quelqu'un d'autre.

Distinguez l'élévation de l'appartenance ordinaire. L'agent peut attribuer un rôle standard sous autorisation de session, tandis qu'un pouvoir de propriétaire, d'administration ou de facturation exige une approbation par appel. La frontière suit la conséquence de la clé, pas la méthode HTTP. `PATCH /users/123` peut être banal ou désastreux selon un seul champ.

Employez les contrôles de comparaison lorsqu'ils existent. Un ETag avec `If-Match`, un champ de version ou une révision empêche d'écraser une intervention humaine postérieure à la prélecture. En cas de conflit, relisez et arrêtez-vous. Ne forcez pas immédiatement le plan original après avoir récupéré la nouvelle valeur : le changement concurrent peut être l'information essentielle.

L'entrée du journal doit contenir l'ancienne valeur, la valeur demandée et observée, l'identifiant distant, le statut de réponse et le jeton de concurrence, mais jamais le jeton d'autorisation. Exemple minimal :

```json
{
  "operation_id": "prov_2026_07_24_0187",
  "step": 3,
  "action": "role.set",
  "subject_id": "usr_1938",
  "before": "guest",
  "requested": "member",
  "observed": "member",
  "http_status": 200,
  "undo": {"action": "role.set", "value": "guest"}
}
```

Un succès de mise à jour ne suffit pas. Relisez la ressource et confirmez la valeur effective. Une API peut répondre `202 Accepted`, appliquer le changement de façon asynchrone ou séparer les états en attente et actif. Le journal reste à `requested` jusqu'à ce qu'une lecture établisse `observed`.

Si la rétrogradation compense l'opération, déterminez si elle exige elle-même une approbation. Restaurer `guest` après un passage accidentel à propriétaire est souvent plus sûr que d'attendre, mais une compensation automatique peut contredire une correction humaine. Autorisez-la seulement tant que la version distante correspond à celle créée par l'opération ; sinon, arrêtez-vous et montrez l'écart.

## Ajoutez chaque groupe dans un appel distinct

Chaque appartenance doit avoir sa propre étape, sa cible distante, son résultat et son instruction inverse. Les groupes cachent souvent des accès étendus. `engineering` peut contrôler des dépôts, des consoles de déploiement, des canaux d'incident et des applications attribuées par synchronisation. Le nom convivial ne suffit pas à mesurer cet impact.

Résolvez les groupes depuis un catalogue autorisé, maintenu hors du prompt. Il associe le nom affiché à un identifiant immuable propre au tenant et précise si l'appartenance est directe, imbriquée, dynamique ou synchronisée. Deux noms identiques doivent provoquer un refus. Un groupe piloté par une règle ne doit pas subir des écritures directes répétées qui combattent cette règle.

L'API Directory du Google Admin SDK matérialise cette frontière : elle sépare l'ajout d'un membre, sa modification et sa suppression par DELETE. Sa documentation indique aussi qu'une appartenance imbriquée peut mettre du temps à apparaître et qu'un cycle est rejeté. Il faut donc observer l'état plutôt que supposer une cohérence immédiate.

SCIM propose un comportement utile. Dans l'exemple PATCH de RFC 7644, l'ajout d'un membre déjà présent ne doit rien modifier et doit réussir. Cela facilite une reprise, mais toutes les implémentations ne suivent pas forcément l'exemple à la lettre. Testez le fournisseur et gardez une lecture de rapprochement.

Une étape de groupe distingue `added`, `already_present`, `rejected` et `unknown`. `Already_present` ne crée aucune compensation, car la suppression effacerait un accès antérieur. `Unknown` signifie que l'écriture a peut-être abouti, mais que la réponse ou la vérification a échoué. Il exige un rapprochement, pas une nouvelle écriture optimiste.

Traitez les groupes par privilège croissant. Ajoutez la collaboration de base avant l'administration de production. L'échec n'est pas sans conséquence, mais le sujet conserve moins d'accès à l'arrêt. Demandez une nouvelle approbation à chaque frontière sensible, même après le succès des groupes ordinaires.

Ne parallélisez pas les écritures pour gagner quelques secondes. Elles brouillent les preuves, compliquent les limites de débit et peuvent déclencher les systèmes en aval dans un ordre imprévisible. Quelques appels séquentiels coûtent moins qu'une enquête sur une licence attribuée avant l'accord d'accès aux données.

Après chaque ajout, lisez l'appartenance directe plutôt qu'une vue aplatie des droits effectifs. L'accès effectif peut venir d'un groupe parent et subsister après la suppression du lien direct. Le reçu doit nommer précisément le lien créé par l'opération.

## Une reprise sûre commence par l'état observé

Une politique de reprise ne transforme pas un POST quelconque en opération sûre. RFC 9110 définit PUT, DELETE et les méthodes sûres comme idempotents par effet voulu. Il déconseille de reprendre automatiquement une requête non idempotente, sauf si sa sémantique l'est réellement ou si l'on sait que l'originale n'a jamais été appliquée.

Le cas dangereux est l'expiration après l'envoi d'un POST d'invitation. Le serveur a pu créer l'invitation et envoyer le courriel avant la rupture. Répéter le POST peut dupliquer l'un ou l'autre. Il faut d'abord lire par sujet et tenant, puis adopter l'objet correspondant, ne reprendre qu'après avoir prouvé l'absence, ou s'arrêter devant une ambiguïté.

Utilisez une clé d'idempotence lorsque l'API en documente une. Dérivez-la de l'identifiant immuable de l'opération et du numéro d'étape, enregistrez-la et réutilisez-la pour la même tentative logique. Une nouvelle clé après expiration indique au serveur une nouvelle action.

Sans cette clé, construisez une fonction de rapprochement pour chaque écriture avant de la confier à l'agent. Elle doit trouver l'objet avec une correspondance exacte : adresse et tenant pour une invitation, utilisateur et groupe pour un lien. Si l'API ne le permet pas, un résultat incertain requiert une confirmation humaine.

Fixez aussi un budget de reprises. Respectez `Retry-After`, appliquez une attente croissante et bornée aux erreurs transitoires, puis arrêtez-vous face aux erreurs de validation, d'autorisation ou de conflit. Un 403 n'est pas un 200 retardé. Représenter sans cesse le même refus apprend également aux opérateurs à approuver sans lire.

Un exécuteur fiable suit cette table :

| Résultat | Action suivante |
|---|---|
| Succès certain et état vérifié | Valider le reçu de l'étape |
| Échec certain sans changement | Journaliser et arrêter |
| Expiration après envoi | Rapprocher avant toute reprise |
| Réponse réussie mais vérification différente | Journaliser l'écart et arrêter |
| Limite de débit avec indication | Attendre dans le budget |

Séparez les tentatives de transport des étapes logiques. Cinq essais HTTP peuvent correspondre à un seul ajout. Le journal principal affiche le résultat logique et les traces liées conservent statuts et durées. Sinon, un auditeur peut prendre des reprises pour plusieurs attributions.

## Le retour arrière est une compensation

Le provisionnement SaaS offre rarement une transaction distribuée. Il faut donc compenser dans l'ordre inverse : retirer les appartenances créées, restaurer le rôle précédent, puis annuler l'invitation encore en attente. Chaque compensation est un véritable appel, susceptible d'échouer, d'exiger une approbation ou de rencontrer un changement concurrent.

Construisez la pile à partir des changements confirmés, pas du plan. Un groupe déjà présent ne doit pas être retiré. Un rôle jamais modifié ne doit pas être restauré. Si la vérification reste inconnue, rapprochez l'état avant de décider.

Un reçu utile conserve assez d'informations pour tenter et limiter l'annulation :

```json
{
  "action": "group.add",
  "target": {"user_id": "usr_1938", "group_id": "grp_77"},
  "result": "added",
  "remote_version_after": "W/\"9012\"",
  "compensation": {
    "action": "group.remove",
    "only_if_direct_membership_matches": true
  }
}
```

La garde de version compte. Si l'agent ajoute Priya puis qu'un responsable confirme indépendamment ce choix dans la console, une annulation aveugle peut effacer une décision désormais détenue par une autre personne. Quand DELETE ne permet pas d'exprimer la condition, relisez le lien et ses métadonnées, montrez le conflit et demandez une décision.

Certains effets n'ont aucune compensation. Un courriel ne peut être rappelé, un événement d'audit ne doit pas disparaître, une licence peut affecter la facturation et un fournisseur d'identité en aval peut propager le changement tardivement. Marquez ces effets résiduels au lieu d'annoncer un retour complet.

La compensation a besoin d'une échéance et d'une voie d'escalade. Les secrets expirent, le service tombe et le processus agent se termine. Persistez les reçus hors du contexte de l'agent afin qu'un autre exécuteur de confiance continue. L'opérateur doit voir `rollback_pending`, pas un échec discret dans une transcription.

Testez le mécanisme sur un tenant hors production : créez puis annulez une invitation et vérifiez le lien ; ajoutez puis retirez un lien direct et contrôlez l'accès effectif ; changez un rôle peu risqué et restaurez-le en présence d'un conflit. La documentation donne l'intention, ces exercices révèlent le comportement réel.

## Le journal doit prouver la cause et l'effet

Un journal utile dit qui a demandé le changement, quel processus l'a exécuté, quelle frontière de secret l'a autorisé, quel objet distant a changé et comment le résultat a été vérifié. Une transcription d'outils ne suffit pas. Le récit de l'agent peut être faux et les corps HTTP trop sensibles ou volumineux.

Donnez des identifiants stables aux opérations et étapes. Conservez le hachage du plan, le tenant exact, le sujet normalisé, les identifiants distants, la décision, l'empreinte de requête, le statut, la lecture de contrôle et la compensation. Ne gardez des extraits expurgés que s'ils expliquent le résultat ; le hachage d'une réponse permet une comparaison sans copier de données personnelles.

Séparez demande et observation. `requested_role: member` décrit l'intention, `response_status: 200` le transport, et `observed_role: member` l'état distant vérifié. Un seul booléen `success` détruit les preuves utiles pendant un incident.

La vue en ligne de commande doit rendre un résultat partiel évident :

```text
$ provision status prov_2026_07_24_0187
STEP  ACTION                 RESULT            UNDO
1     invitation.create      accepted          unavailable
2     acceptance.wait        observed          n/a
3     role.set               changed           ready: guest
4     group.add engineering  added             ready
5     group.add on-call      denied            none
STATE partial_failure
```

Cette sortie montre que le compte existe, que le rôle a changé, qu'un groupe a été ajouté et que le dernier a échoué. Elle ne réduit pas tout à « échec du provisionnement ». La distinction guide aussi bien la compensation que la reprise après correction de l'autorisation.

Protégez le journal contre l'agent qui agit. S'il peut réécrire ses preuves, elles valent peu. Sallyport projette les sessions et appels individuels depuis un seul journal chiffré et chaîné par hachage ; `sp audit verify` vérifie la chaîne hors ligne, sur le texte chiffré et sans clé. Cela ne remplace pas le journal du fournisseur, mais fournit une séquence locale indépendante.

Reliez les identifiants d'étape locaux aux identifiants de requête du fournisseur. Le support retrouve ainsi les traces du serveur tandis que le journal explique l'intention et l'approbation. Gardez les horodatages, mais ordonnez par une séquence locale monotone, car horloges et événements asynchrones peuvent diverger.

La conservation exige une politique explicite. Les preuves contiennent parfois adresses, groupes et historique de rôles. Gardez les champs minimaux, chiffrez-les, limitez les lecteurs et faites expirer les réponses auxiliaires avant l'enregistrement central lorsque la politique le permet.

## Placez l'approbation à la frontière des conséquences

Une carte d'approbation fonctionne lorsqu'elle décrit une conséquence concrète. « Autoriser le provisionnement » est trop vague. « Inviter priya@example.test dans acme-production sans envoyer de courriel » est vérifiable. « Passer usr_1938 de guest à member » et « ajouter usr_1938 à production-deployers » méritent des décisions séparées si leurs risques diffèrent.

Affichez les identifiants résolus et l'état courant, pas seulement les mots de l'agent. La carte indique le tenant, le sujet canonique, l'action, l'avant, l'après et la compensation disponible. Pour une invitation, précisez l'envoi du courriel ; pour un groupe, montrez l'identifiant immuable avec son nom.

L'autorisation de session peut couvrir les appels répétitifs peu risqués, tandis qu'une clé ou une action sensible exige un accord à chaque usage. L'échelle fixe de Sallyport applique cette séparation : le coffre doit être déverrouillé, un nouveau processus reçoit par défaut une autorisation de session, et un indicateur par clé peut imposer une approbation à chaque appel. Placez la clé privilégiée derrière la frontière stricte au lieu de demander au modèle de se contrôler lui-même.

L'approbation ne répare pas une mauvaise sémantique d'exécution. Une personne peut approuver le bon groupe et subir un POST dupliqué après expiration. L'exécuteur garde la responsabilité de l'idempotence, de la vérification et de la compensation. Un journal parfait ne rend pas sûre une clé trop puissante.

Réduisez la fatigue en supprimant les demandes sans décision. Les lectures limitées peuvent relever de la session. Les absences de changement exactes doivent être consignées sans demander d'« approuver » ce qui n'arrivera pas. Ne groupez des appartenances identiques et peu risquées que si l'interface montre toutes les cibles et conserve des reçus distincts.

La révocation doit bloquer les étapes futures sans prétendre inverser les étapes achevées. Si l'opérateur révoque après la quatrième étape, l'exécuteur annule les appels en attente, marque l'opération interrompue et propose la compensation. Il ne change pas secrètement de clé et n'ouvre pas une autre session.

## Une exécution en échec doit rester intelligible

Imaginons l'arrivée d'une prestataire avec un compte ordinaire et deux groupes. La prélecture ne trouve aucun compte. L'invitation expire après envoi ; le rapprochement trouve une invitation en attente et adopte son identifiant. La prestataire accepte, le rôle change, le premier groupe est ajouté, puis le second renvoie 403 faute d'autorité du jeton.

C'est un résultat partiel, pas une erreur indifférenciée. Il existe maintenant un compte actif et un lien direct de groupe. L'agent doit s'arrêter, montrer l'étape refusée et proposer deux choix : conserver l'état confirmé en attendant l'autorité nécessaire, ou compenser le premier groupe et restaurer le rôle avant de traiter le compte.

Il ne doit pas supprimer l'utilisateur : cela peut enlever des données, invalider une identité acceptée ou heurter un système en aval. Il ne doit pas reprendre le 403, prétendre rappeler le courriel ni remplacer le groupe refusé par un groupe plus large.

Le journal permet une reprise sûre. Un nouvel exécuteur charge le plan immuable et les reçus, relit l'état distant et confirme que compte, rôle et premier groupe correspondent toujours. Si oui, il demande uniquement l'approbation du groupe restant. Si un responsable a changé le rôle, le plan est périmé et exige une nouvelle décision.

Le modèle s'applique aussi au départ d'un utilisateur. Révocation de session, retrait des groupes, changement de rôle, suspension et suppression diffèrent en urgence et en réversibilité. Une licence doit rester séparée d'un groupe lorsque l'API les sépare. La règle demeure : conserver dans le plan et les preuves les frontières d'état significatives du système distant.

Les appels supplémentaires introduisent une friction volontaire. Ils offrent des points pour vérifier l'identité, limiter l'autorité, s'arrêter en cas d'écart et annuler uniquement les changements de l'opération. Un agent autonome peut recevoir plus de liberté lorsque son travail reste inspectable à ces frontières. Si une API impose plusieurs conséquences dans un appel irréversible, classez-le honnêtement et placez une personne devant lui.