Et si l'IA devenait
un recrutement comme un autre ?
Des fiches de poste pour des agents. Des CRM pour les gérer. Une réglementation européenne pour les encadrer. Des temps d'arrêt obligatoires. Ce n'est pas de la science-fiction — c'est la direction logique de ce qu'on construit aujourd'hui.
Ce n'est pas un hasard. Quand on définit un agent IA — son périmètre d'action, ses règles de décision, ses escalades obligatoires, ses horaires d'activité — on fait exactement ce qu'un DRH fait quand il recrute : on définit un rôle, ses responsabilités, et les conditions d'exercice.
La différence, aujourd'hui, c'est qu'on le fait de façon informelle, dans un prompt système, sans cadre, sans traçabilité, sans processus commun d'une organisation à l'autre. Dans cinq ans, je ne crois pas que ce soit tenable.
Cet article est une projection. Pas une prédiction — une extrapolation raisonnée de là où mènent les tendances actuelles : l'AI Act européen, la multiplication des agents en production, l'émergence des tours de contrôle, et la question qui s'impose progressivement à toutes les équipes qui opèrent des agents : comment on gère ça, vraiment, à l'échelle ?
La fiche de poste d'un agent IA — exercice de style ou nécessité ?
Voici ce que pourrait ressembler le recrutement d'un agent spécialisé dans un contexte MFT, dans un horizon de trois à cinq ans. Pas une parodie — un document de travail sérieux, avec les mêmes exigences qu'on appliquerait à un prestataire humain.
Version 2.1 · Mars 2026
Ce document n'existe pas encore dans ce format standardisé. Mais chaque ligne correspond à quelque chose que j'ai déjà écrit quelque part — dans un prompt, dans une documentation technique, dans une note à la RSSI. La fiche de poste, c'est juste la formalisation de ce qu'on fait déjà de façon éparpillée.
Le CRM des agents — gérer un parc à l'échelle
Une entreprise avec dix agents peut les suivre dans un tableau. Avec cinquante, ça devient un problème de gestion. Avec deux cents — ce qui est réaliste d'ici trois ans pour une grande organisation — il faut un outil dédié.
Les CRM RH existent pour gérer les collaborateurs humains : historique, performance, formation, contrats. La logique d'un CRM pour agents IA n'est pas fondamentalement différente.
Ce que ce CRM rend possible, ce n'est pas juste du monitoring. C'est une mémoire institutionnelle des agents — l'historique de leurs décisions, de leurs incidents, de leurs évolutions. Quand un agent est remplacé, mis à jour, ou simplement questionné par un auditeur, cette traçabilité devient indispensable.
« Un agent sans historique, c'est un prestataire sans CV, sans références, et sans contrat signé. Vous lui confieriez l'accès à vos systèmes de production ? »
La réglementation européenne — ce qui existe déjà, ce qui arrive
On a tendance à traiter la gouvernance des agents IA comme un sujet futur. C'est une erreur. Le cadre réglementaire est déjà partiellement en place — et il va s'accélérer.
Les temps d'arrêt obligatoires — une idée absurde ?
C'est la proposition la plus provocante de cet article, et pourtant celle qui me semble la plus logique une fois qu'on y réfléchit sérieusement.
Un agent IA qui tourne 24h/24, 7j/7, sans interruption, sans mise à jour, sans révision — c'est un risque opérationnel. Les modèles évoluent. Les contextes changent. Ce qui était un comportement correct en janvier peut devenir problématique en juin si le contexte métier a changé et que personne n'a mis à jour les règles de l'agent.
Les infrastructures critiques ont des fenêtres de maintenance obligatoires. Les pilotes d'avion ont des limites de temps de vol. Les médicaments ont des dates de péremption. Ces contraintes existent parce qu'on a appris — parfois douloureusement — que l'absence d'interruption forcée est un vecteur de risque systémique.
Un agent IA en production continue sans révision, c'est le même problème. La dérive comportementale que j'évoquais dans l'article sur la tour de contrôle est précisément amplifiée par l'absence de points d'arrêt forcés.
Ce parallèle n'est pas une métaphore poétique. C'est une grille de lecture opérationnelle. Chaque contrainte qui s'applique au collaborateur humain a une raison d'être — protéger l'organisation, l'individu, et les tiers. Ces mêmes raisons s'appliquent aux agents autonomes.
Le décommissionnement — l'angle mort de tous les projets
Tout le monde parle de déployer des agents. Presque personne ne parle de les retirer.
Pourtant, le cycle de vie d'un agent inclut nécessairement sa fin. Le modèle sous-jacent devient obsolète. Le use case disparaît. L'organisation change. La réglementation évolue. Et là, concrètement, que fait-on ?
- Un agent retiré sans documentation laisse des décisions passées inexplicables — problème majeur en cas d'audit ou de litige
- Des dépendances non cartographiées : d'autres systèmes ou agents continuent d'envoyer des requêtes à un agent qui n'existe plus
- Des données traitées par l'agent (logs, contextes, historiques) qui ne sont pas archivées selon les obligations réglementaires
- Un remplacement précipité par un nouvel agent sans période de transition — perte de la mémoire opérationnelle accumulée
Le décommissionnement d'un agent devrait être aussi formalisé que son onboarding. Un rapport de fin de mission. Un archivage des logs. Une revue des décisions prises. Et, si l'agent est remplacé, un plan de transition qui préserve la continuité opérationnelle.
Ce que ça change pour ceux qui construisent aujourd'hui
Cette projection ne vise pas à effrayer. Elle vise à orienter. Si la direction est celle que je décris — et je pense qu'elle l'est, même si le calendrier est incertain — alors certaines décisions qu'on prend aujourd'hui dans la construction des agents ont des implications durables.
- Versionner les prompts système comme du code — avec historique, commentaires, et possibilité de rollback. Ce n'est pas une contrainte supplémentaire, c'est de l'hygiène.
- Documenter le périmètre de chaque agent dans un registre — même minimal. Qui l'a créé, pour quoi faire, quelles décisions il peut prendre seul, et qui en est responsable.
- Définir les conditions de suspension avant le déploiement, pas en réaction à un incident. Un kill switch sans procédure est une illusion de contrôle.
- Anticiper la question réglementaire — si votre organisation est dans le secteur financier, l'AI Act vous concerne déjà pour certains use cases. Une revue préventive vaut mieux qu'une mise en conformité forcée.
- Traiter le décommissionnement comme une exigence dès le design — pas en fin de projet. Comment cet agent sera-t-il retiré ? Que laissera-t-il derrière lui ?
Le vrai sujet n'est pas l'agent. C'est notre rapport à la délégation.
Ces trois articles — l'onboarding agent-à-agent, la tour de contrôle, et maintenant cette projection sur le statut des agents — convergent vers la même question fondamentale : à qui, et à quoi, sommes-nous prêts à déléguer des décisions réelles ?
La réponse n'est pas technique. Elle est organisationnelle, éthique, et réglementaire. La technologie, elle, est déjà là — ou presque. Ce qui n'est pas prêt, dans la plupart des organisations, c'est le cadre qui permet de lui faire confiance sans naïveté.
Construire un agent sans penser à sa gouvernance, c'est recruter sans contrat. Ça fonctionne tant que tout va bien. Le jour où ça se complique, l'absence de cadre amplifie chaque problème.
Je construis mon premier agent en ce moment. Et la question que je me pose chaque semaine n'est plus "est-ce que ça marche ?" Elle est : "est-ce que je serai capable d'expliquer ce qu'il a fait, pourquoi, et ce que j'ai fait pour m'en assurer ?"
Si la réponse est oui, on peut avancer.
Cette série de trois articles — onboarding agent-à-agent, tour de contrôle, et statut des agents — explore où mène logiquement ce qu'on construit aujourd'hui. Pas des prédictions. Des extrapolations ancrées dans le terrain.