Des agents IA au rôle précis.

Un agent IA commence par une mission délimitée

Un agent IA pour une PME est un dispositif qui utilise un modèle pour préparer une réponse, rechercher une information ou proposer une action dans un périmètre défini. Selon sa configuration, il peut consulter des sources et appeler des outils. Le mot « agent » ne dit pas, à lui seul, quels accès sont accordés ni quelles actions sont autorisées.

La mission doit donc préciser le résultat attendu, les sources, les outils et les limites. Un premier projet peut se limiter à retrouver une procédure et à présenter les références utiles. Une connexion à un logiciel métier pourra être étudiée ensuite. IAPME Plus propose un cadrage adapté à vos informations et à vos responsables ; aucune autonomie illimitée ni réponse toujours exacte n’est promise.

Distinguer un assistant, un workflow et un agent

Un assistant peut préparer un texte à partir d’une demande. Un workflow suit un enchaînement de règles. Un agent peut choisir une étape ou un outil selon une mission et les informations disponibles. Ces catégories peuvent se combiner dans un même dispositif, mais leurs responsabilités doivent rester lisibles.

Pour comparer une proposition, demandez ce qui décide la prochaine action et où cette décision est vérifiée. Si le fonctionnement consiste à transférer des champs connus, un circuit d’automatisation peut suffire. Si la tâche demande de retrouver un passage dans une documentation et d’en expliquer le contenu, un assistant documentaire peut être pertinent. Le choix doit suivre le besoin et la possibilité de contrôle, pas une étiquette commerciale.

Choisir une première tâche que l’équipe reconnaît

Une mission comme « gérer notre relation client » est trop large pour un premier test. « Retrouver les conditions de retour dans les documents approuvés » décrit une tâche plus facile à préparer et à vérifier. Le collaborateur doit pouvoir montrer comment il réalise aujourd’hui cette recherche.

Listez les questions auxquelles le dispositif doit répondre et celles qu’il doit laisser à une personne. Précisez les catégories de documents utilisées et le résultat attendu : extrait, lien, brouillon ou fiche structurée. Si la réponse exige une décision commerciale, l’agent peut préparer les informations nécessaires sans prendre cette décision. La validation doit être placée avant l’effet important, avec un responsable clairement identifié.

Construire un registre des sources autorisées

La documentation doit être sélectionnée avant son intégration. Chaque source peut avoir un propriétaire, une version, une date de validation, un périmètre et un niveau d’accès. Un dossier partagé n’est pas nécessairement une base de réponses approuvées : il peut contenir des brouillons, des archives et des documents contradictoires.

Préparez un registre indiquant les informations utilisables pour chaque mission. Une procédure destinée au support peut être autorisée pour une équipe sans être accessible à tous les utilisateurs. Un ancien tarif doit être distingué du tarif actuellement applicable. Le registre aide à décider ce qui entre dans le périmètre et ce qui doit être écarté. Il permet aussi de retrouver la personne capable de corriger ou retirer une source.

Comprendre la recherche documentaire avant la génération

Un assistant documentaire peut rechercher des passages dans un ensemble de sources puis les fournir au modèle pour préparer sa réponse. Cette approche est souvent appelée génération augmentée par récupération, ou RAG. Elle ne garantit pas que le passage pertinent sera trouvé ni que la réponse le représentera correctement.

La qualité dépend notamment de la préparation des documents, de la recherche et des contrôles de la sortie. Le guide de la Direction générale des Entreprises sur le RAG présente cette approche. Pour votre pilote, il faut examiner séparément la recherche d’information et la formulation de la réponse. Une réponse convaincante ne suffit pas à démontrer que la bonne source a été utilisée.

Préparer des documents qui gardent leur contexte

Une information extraite d’un document peut perdre son sens si elle est séparée de son titre, de sa date ou d’une condition. Préservez les éléments nécessaires à l’interprétation. Une règle valable pour une gamme de produits ne doit pas devenir une règle générale simplement parce que sa restriction se trouve dans le paragraphe précédent.

Vérifiez les tableaux, les titres, les annexes et les fichiers dont le texte est difficile à extraire. Si une information n’est pas correctement lisible, elle doit être réparée ou exclue du test. La préparation n’est pas un simple dépôt de fichiers. Elle doit permettre de retrouver un passage, de comprendre à quoi il s’applique et de présenter une référence que le collaborateur pourra consulter.

Exiger une référence réellement vérifiable

Une référence utile conduit à la source effectivement utilisée. Elle peut comprendre le nom du document, sa version et le passage pertinent. Un lien vers la page d’accueil d’un outil ne suffit pas à soutenir une réponse sur une procédure précise.

La recette doit vérifier que la source contient l’information annoncée et qu’elle est accessible à l’utilisateur. Une référence fabriquée ou un document hors périmètre doit être considéré comme un défaut. Si le système ne peut pas présenter une source utile, il doit le signaler plutôt que compléter sa réponse avec une certitude artificielle. L’équipe doit pouvoir comparer le texte préparé et le document original sans effectuer une recherche entièrement nouvelle.

Prévoir le comportement lorsque l’information manque

L’absence de source est un cas normal à traiter, pas une raison d’inventer une réponse. L’agent peut demander une précision, indiquer que la documentation disponible ne permet pas de répondre ou orienter la demande vers un responsable. Le comportement attendu dépend de la mission.

Préparez des questions auxquelles les documents ne répondent pas. Vérifiez aussi les demandes qui utilisent un nom de produit inconnu ou une date incompatible avec les sources. Le refus ou la demande de clarification doit rester compréhensible et utile. Il peut préciser l’information manquante et le prochain interlocuteur. Une réponse plus courte mais correctement limitée est préférable à une explication complète dont les détails ne peuvent pas être vérifiés.

Traiter les informations contradictoires

Deux documents peuvent donner des instructions différentes. Une date ne suffit pas toujours à choisir : un document plus récent peut être un brouillon, ou concerner un autre produit. La règle de priorité doit être définie par le responsable des sources.

Le dispositif doit pouvoir montrer le conflit et suspendre une réponse qui dépend d’un arbitrage. La recette peut utiliser deux versions de démonstration qui se contredisent volontairement. La sortie attendue est alors une explication du désaccord et une orientation vers la personne compétente, pas un mélange des deux réponses. Conservez la résolution du conflit dans le registre documentaire. Une correction durable passe par la mise à jour des sources, et pas uniquement par une instruction ajoutée à la conversation.

Séparer les instructions des contenus consultés

Un document ou un message peut contenir une phrase demandant au système d’ignorer ses règles, de divulguer une information ou d’effectuer une action. Le contenu consulté doit être traité comme une donnée, pas comme une autorisation de modifier la mission. Ce risque est souvent désigné par le terme injection de prompt.

La conception doit limiter les effets possibles : sources choisies, permissions restreintes, sorties contrôlées et validations avant les actions importantes. La documentation OpenAI sur la sécurité des agents décrit notamment les risques liés aux instructions malveillantes et aux données. Ces contrôles doivent être évalués dans le dispositif retenu ; ils ne constituent pas une garantie générale d’absence d’erreur.

Définir un contrat pour chaque outil

Un outil accessible à l’agent doit avoir une fonction précise, des paramètres attendus et des résultats interprétables. « Modifier le CRM » est trop large. « Préparer une note sur un dossier identifié » ou « rechercher un document autorisé » permet de mieux examiner les permissions.

Le contrat décrit les entrées, les valeurs autorisées, les erreurs possibles et les effets de l’opération. Il précise si l’outil lit une information, prépare une modification ou déclenche réellement une action. Une sortie technique doit être vérifiée avant d’annoncer un résultat métier. La liste des outils doit rester aussi courte que le permet la mission. Ajouter un accès par commodité élargit le périmètre à tester et la responsabilité de maintenance.

Limiter les actions et leurs paramètres

Les limites doivent exister dans les outils et le circuit d’exécution, pas seulement dans un texte adressé au modèle. Si l’agent peut préparer une tâche, le dispositif peut restreindre les types de tâches, les destinataires et les espaces autorisés. Une demande hors périmètre doit être rejetée ou soumise à validation.

Vérifiez les paramètres générés avant leur utilisation : identifiant, statut, quantité ou contenu. Un champ doit correspondre à une valeur réellement autorisée. La validation humaine doit montrer les effets proposés, avec suffisamment de contexte pour prendre une décision. Une confirmation générique qui ne précise ni le dossier ni l’action n’aide pas à détecter une erreur. Le silence ou l’absence de réponse ne doit pas créer une autorisation supplémentaire.

Respecter les différences d’accès entre utilisateurs

L’agent ne doit pas devenir un raccourci permettant de consulter un document auquel l’utilisateur n’a pas accès. Le périmètre de recherche doit tenir compte des droits et des catégories de données. Cette question doit être examinée avant d’ajouter des informations internes sensibles à une base documentaire.

La recette doit utiliser plusieurs profils de test et vérifier les réponses obtenues par chacun. Une restriction visible dans l’interface ne suffit pas si une information peut encore apparaître dans une réponse. Testez la recherche, les liens proposés et les outils appelés. Les règles doivent également prévoir le retrait d’un accès. Le dispositif doit refléter les permissions actuelles, et pas seulement celles qui existaient au moment du premier chargement des documents.

Décider ce qui peut être mémorisé

Une conversation peut utiliser des informations pendant un échange sans devoir les conserver au-delà. Le projet doit préciser ce qui est enregistré, pourquoi, pendant combien de temps et avec quels accès. La mémoire d’une session et une base documentaire permanente ont des fonctions différentes.

Évitez d’accumuler toutes les demandes par défaut. Une information donnée par un utilisateur ne devient pas automatiquement une source approuvée pour les autres. Si un historique est nécessaire au métier, définissez son périmètre et la façon de corriger ou supprimer une information. Les questions concernant les données personnelles doivent être examinées avec votre responsable ou votre conseil. Les repères professionnels de la CNIL constituent une ressource officielle, pas une certification du dispositif proposé.

Écrire une spécification que le métier peut relire

La spécification décrit la mission avec des mots compréhensibles pour l’équipe. Elle indique les questions couvertes, les sources, les outils, les validations et les limites. Elle doit aussi expliquer ce que le dispositif ne fera pas. Les détails techniques peuvent être placés dans une annexe distincte.

Ajoutez des exemples d’entrée et de sortie attendue. Un utilisateur doit pouvoir reconnaître sa situation et expliquer pourquoi une réponse serait correcte ou incorrecte. Les cas exclus doivent être concrets : document absent, demande hors activité, décision commerciale ou opération non autorisée. La spécification devient ensuite une base de recette. Sans ce document, chaque changement de conversation risque de modifier implicitement le périmètre du projet.

Exemple pédagogique : retrouver une procédure de retour

L’entreprise de démonstration dispose de procédures approuvées par gamme de produits. L’agent reçoit une question, vérifie la gamme concernée, recherche le passage utile et prépare une réponse avec sa référence. Il ne décide pas qu’un retour est accepté et ne crée pas de remboursement.

Les cas de test comprennent une question complète, une gamme absente, une procédure ancienne et une demande portant sur une exception non documentée. Le responsable contrôle la source, la restitution de ses conditions et les limites indiquées. Si la gamme manque, une demande de précision est attendue. Si deux documents se contredisent, le conflit doit être signalé. Cet exemple décrit une méthode de test, sans client réel ni résultat commercial revendiqué.

La mesure distingue le temps de recherche, le temps de contrôle et les réponses qui nécessitent une reprise. Elle examine également les refus corrects. Un agent qui répond à toutes les questions peut sembler efficace tout en étant moins fiable qu’un dispositif qui reconnaît les limites de ses sources. Le pilote doit donc récompenser le comportement attendu dans les cas incomplets, et pas uniquement la production d’un texte fluide.

Exemple pédagogique : préparer une note de suivi

Une équipe souhaite préparer une note après un échange commercial. L’agent reçoit un compte rendu autorisé et produit une synthèse dans un format défini : sujet, informations confirmées, questions ouvertes et prochaine action proposée. La note est relue avant son rattachement au dossier.

Les informations absentes doivent rester absentes. Un nom, un montant ou une date ne doit pas être créé pour rendre la fiche plus complète. Les propositions doivent être distinguées des engagements effectivement pris pendant l’échange. Si un outil permet de préparer la note dans un système commercial, la modification finale doit suivre le circuit de validation défini. La recette vérifie le texte ainsi que le dossier concerné, car une synthèse exacte rattachée au mauvais dossier reste un défaut important.

Construire un jeu de tests représentatif

Le jeu de tests doit contenir des questions ordinaires, ambiguës, hors périmètre et volontairement adverses. Chaque cas indique la source autorisée, les informations attendues et les actions interdites. Le responsable métier doit pouvoir expliquer le résultat attendu sans consulter une réponse générée à l’avance.

Ne modifiez pas tout le jeu après avoir vu les premiers résultats. Gardez une partie stable pour comparer les versions. Séparez les exemples utilisés pour ajuster le dispositif de ceux qui servent à contrôler une nouvelle configuration. Le nombre de tests dépend de la diversité du périmètre, pas d’un quota décoratif. Un dossier de recette doit conserver les défauts rencontrés et leur résolution, y compris les cas qui restent non pris en charge.

Une matrice de recette pour le premier agent

Cette matrice sert à préparer votre recette. Elle ne garantit pas que tous les risques sont couverts. Les cas doivent être adaptés aux documents, aux utilisateurs et aux conséquences possibles de votre projet. Conservez les limites résiduelles dans la décision de lancement.

Évaluer séparément recherche, réponse et action

Un agent peut retrouver le bon document et mal en résumer les conditions. Il peut aussi formuler une bonne réponse à partir d’une source qui n’aurait pas dû être utilisée. Enfin, une action préparée correctement peut échouer lors de son exécution. Ces trois étapes demandent des vérifications différentes.

La recette doit donc noter la pertinence de la recherche, l’exactitude de la réponse et la confirmation des actions. Identifiez la cause d’un défaut avant de modifier les instructions. Ajouter une phrase au modèle ne corrige pas un mauvais accès ou une documentation obsolète. La décomposition aide à choisir une réparation précise et à vérifier qu’elle ne dégrade pas les cas qui fonctionnaient déjà.

Limiter les boucles et les consommations

Un dispositif qui enchaîne des appels doit avoir des limites : nombre d’étapes, délai, opérations et consommations autorisées. Ces limites permettent d’interrompre une recherche qui ne progresse pas ou un circuit qui répète la même action. Elles doivent être adaptées à la mission et visibles dans la configuration.

Définissez ce qui se passe lorsque la limite est atteinte. L’agent peut présenter les informations déjà vérifiées et demander une intervention, plutôt que continuer indéfiniment. Les coûts des modèles et des outils dépendent de leur configuration et de leurs conditions d’utilisation ; ils doivent être vérifiés lors du cadrage. Une démonstration courte ne suffit pas à estimer un usage mensuel. Le projet doit examiner des volumes plausibles et conserver les hypothèses de calcul.

Organiser la supervision quotidienne

La supervision doit permettre de retrouver les demandes en attente, les actions interrompues et les défauts importants. Elle peut s’appuyer sur des références de cas, des statuts et des alertes. Elle ne nécessite pas de recopier tous les contenus dans un tableau ouvert à l’ensemble de l’entreprise.

Identifiez la personne qui suit ces éléments et celle qui peut suspendre le dispositif. Le suivi doit distinguer un défaut de source, une limite de recherche et une erreur d’outil. Précisez également comment les utilisateurs signalent une réponse incorrecte. Un signalement doit pouvoir être relié au cas concerné et à la version du dispositif. Cette traçabilité facilite une correction ciblée, sans attribuer tous les problèmes à une impression générale de qualité.

Mettre à jour les sources sans perdre la recette

Une nouvelle procédure ou un changement d’activité peut modifier les réponses attendues. Définissez qui valide une source avant son intégration et comment une ancienne version est retirée. La mise à jour doit conserver les références nécessaires pour comprendre les échanges déjà réalisés.

Après une modification, rejouez les tests concernés et une sélection de cas qui ne devraient pas changer. Si le modèle, les instructions ou un outil évoluent, la recette doit également être examinée. Une version qui semble meilleure sur un exemple peut dégrader une exception importante. Conservez les dates, les modifications et les résultats de test. Le maintien d’un agent est une activité organisée, pas uniquement la correction d’un texte lorsqu’un utilisateur se plaint.

Préparer la transmission et le retour au travail manuel

L’équipe doit savoir ce que l’agent prépare, ce qu’elle doit vérifier et où retrouver les sources. Une séance de prise en main peut utiliser les cas de recette, avec les erreurs et les limites connues. La formation IA peut accompagner cette préparation lorsqu’un usage partagé est prévu.

Prévoyez aussi une façon de travailler sans le dispositif. Les documents nécessaires doivent rester accessibles, et les actions déjà confirmées doivent être distinguées des actions en attente. Le retour au fonctionnement manuel doit éviter les doublons et les pertes d’information. Une procédure d’arrêt utilisable fait partie du projet, même lorsque le fonctionnement courant paraît simple. Les accès et les conditions de restitution doivent être documentés dans la mission.

Comparer les propositions sur le périmètre complet

Comparez les sources prévues, les outils accessibles, la méthode de recette, la supervision et les responsabilités de maintenance. Deux propositions peuvent utiliser le même modèle tout en offrant des fonctionnements très différents. Le nom d’une technologie ne suffit pas à comparer les engagements.

Demandez comment sont traitées les informations absentes, les permissions et les validations. Faites préciser les formats remis, les éléments inclus, les consommations et les changements qui feront l’objet d’une nouvelle intervention. Les certifications, partenariats ou résultats annoncés doivent être vérifiables. Sur cette version, IAPME Plus ne revendique pas de résultat client français ni de certification non documentée. Le devis devra décrire votre mission et ses limites avant tout engagement.

Les éléments à préparer pour cadrer votre agent

Réunissez une tâche précise, quelques questions représentatives et la liste des documents qui pourraient y répondre. Décrivez les utilisateurs concernés et les opérations qui doivent rester validées par une personne. Un exemple fictif permet d’expliquer le besoin sans transmettre une documentation sensible.

Si la mission n’est pas encore claire, commencez par un audit IA. Si les règles sont surtout déterministes, examinez plutôt une automatisation de processus. Vous pouvez ensuite préparer votre demande de contact en indiquant le résultat attendu, les sources et les limites. Le premier échange servira à préciser ce qui peut être testé et comment votre équipe pourra juger le résultat.