Un processus peut être décomposé en tâches sans que l’autorité de ses décisions soit clairement attribuée. Avec des agents capables d’appeler des outils, cette ambiguïté peut devenir une attribution d’accès, une suppression ou une communication engageante. L’architecture du travail doit donc préciser davantage que l’ordre des étapes.
Je propose d’appeler Architecte de Processus Agentiques la fonction qui relie le besoin métier, la délégation, les contrôles et les preuves attendues. Cette responsabilité peut être portée par une équipe ou par une personne mandatée. Le nom ne suppose ni profession réglementée ni absence de compétences équivalentes dans les organisations.
L’onboarding approuvé change de contenu
Considérons l’arrivée d’un collaborateur. Le responsable autorise un profil de consultation pour un espace documentaire. Un agent prépare la demande, puis un autre l’adapte au catalogue d’habilitations. Une correspondance erronée transforme le profil de lecture en rôle d’administration. Le dossier conserve pourtant une mention « accord obtenu ».
Si le service d’attribution vérifie seulement ce statut, il peut délivrer des droits que personne n’a approuvés. Le collaborateur pourrait alors modifier des documents, supprimer des éléments ou élargir d’autres accès. La gravité dépend des ressources concernées ; l’existence d’un compte correctement authentifié ne rend pas ces permissions appropriées.
Ce défaut peut venir d’un intitulé ambigu, d’un catalogue modifié ou d’une synthèse qui perd les paramètres approuvés. Il n’exige pas d’attribuer une intention malveillante au modèle.
Une approbation porte sur une opération définie. Le mot « approuvé » ne transmet pas un droit général à ses transformations ultérieures.
Concevoir les responsabilités avant l’exécution
La première tâche de conception est de définir ce que le métier veut autoriser : ressource, opérations, durée et conditions particulières. Le responsable métier qualifie le besoin. L’équipe qui possède la ressource définit les habilitations disponibles. La sécurité examine les incompatibilités et les privilèges. L’autorité d’approbation décide dans son mandat. Le composant d’exécution recontrôle la demande qu’il va effectivement appliquer.
Ces responsabilités peuvent se répartir autrement selon l’organisation. Elles doivent néanmoins être identifiables. Un agent chargé de rapprocher des intitulés ne reçoit pas, pour cette raison, le droit de choisir une exception d’habilitation.
La méthode réutilisable doit décrire les entrées attendues, les correspondances admises et le traitement d’une ambiguïté. Lorsqu’un rôle ne correspond pas au profil approuvé, la préparation peut continuer, mais l’attribution sensible doit attendre une décision appropriée. Les recommandations OWASP sur l’intégrité des actions sensibles demandent notamment de lier l’approbation à l’action exacte et de séparer proposition et exécution.
Une exception doit rester une décision explicite
Si le rôle doit réellement changer, le processus doit présenter les nouveaux droits et leur justification à l’autorité compétente. L’ancien accord ne doit pas être réutilisé comme si les paramètres étaient restés identiques. Une comparaison technique révèle une différence ; elle ne décide pas si le nouveau besoin est légitime.
La reprise mérite la même précision. Retirer un accès après sa délivrance ne retire pas les copies de données déjà réalisées ni les modifications effectuées pendant sa validité. Le traitement d’un écart demande donc de connaître les effets, de limiter les nouvelles opérations et d’examiner les mesures de récupération possibles. La réversibilité doit être évaluée, pas présumée.
Comment cette fonction se traduit dans Swarm
Swarm organise des plans, des tâches, des dépendances et des validations. Ses contrats distinguent la production d’un résultat, les preuves de contrôle et la décision permettant de poursuivre. Dans le pilote Trust Rust, la demande d’action, le mandat, les paramètres et l’approbation sont des objets distincts. Un connecteur local d’accès produit des effets simulés ; il ne constitue pas un raccordement à un annuaire d’entreprise.
Ces mécanismes fournissent des points d’appui à une architecture de processus. Ils ne définissent pas à la place du métier le bon profil d’accès. Une identité locale ou un rôle d’approbateur ne démontre pas non plus, à lui seul, l’identité d’un décideur humain. Le raccordement aux ressources, la couverture des voies alternatives et le confinement général restent des conditions à qualifier pour un déploiement réel.
Ce qu’il faut pouvoir expliquer après l’action
Pour notre onboarding, une investigation doit retrouver le profil demandé, les paramètres approuvés, la version du catalogue utilisée, l’auteur de la décision et les droits effectivement attribués. Il faut aussi identifier qui peut suspendre la suite et qui traite l’exception.
Cette fonction conserve sa valeur lorsque les outils ou les modèles changent. Elle rend discutables les frontières de délégation et les critères de réussite, au lieu de laisser l’orchestration les décider implicitement. Le dépôt Swarm expose les contrats que je développe pour soutenir cette démarche.