Creer son premier agent IA en PME: un workflow utile avant un agent spectaculaire

Le test des cinq questions

Avant de choisir un outil, verifiez que le processus merite un agent.

• La tache revient-elle chaque semaine ou chaque jour ?
• Les entrees et le resultat attendu sont-ils definis ?
• Une erreur est-elle detectable avant qu'elle ait un impact ?
• Qui valide ou corrige le resultat ?
• Quel indicateur prouvera le gain de temps, de qualite ou de revenu protege ?

Le workflow minimal

Un agent fiable suit une chaine simple que l'equipe peut lire et auditer.

1. 1

   Declencheur: une demande, un fichier ou une tache planifiee arrive.

2. 2

   Contexte: l'agent lit seulement les informations necessaires et autorisees.

3. 3

   Raisonnement: il applique le playbook ou le skill de l'equipe.

4. 4

   Sortie: il produit un brouillon, une synthese ou une action proposee dans un format defini.

5. 5

   Validation: une personne approuve, corrige ou refuse avant toute action engageante.

Les erreurs frequentes

Les projets echouent rarement par manque de modele. Ils echouent surtout par manque de cadre.

• Connecter trop de donnees avant d'avoir valide un cas d'usage.
• Mesurer seulement le nombre de taches au lieu de la qualite et de l'impact.
• Ne pas prevoir de retour arriere ni de journal des actions.

Choisir un processus suffisamment stable

Un agent ne répare pas un processus que l'équipe ne comprend pas. Choisissez une tâche fréquente dont les entrées, les décisions et la sortie peuvent être décrites. Observez plusieurs exécutions humaines et notez les exceptions. Si chaque cas exige une négociation ou un jugement stratégique, commencez par un assistant qui prépare l'information plutôt que par un agent qui agit.

• Bon candidat : préparer une fiche de qualification depuis un formulaire complet et demander un humain lorsque des champs essentiels manquent.
• Candidat risqué : répondre seul à toutes les demandes clients, car prix, promesses, réclamations et exceptions peuvent engager l'entreprise.
• Indicateur de départ : temps total, erreurs, reprises et dossiers sans prochaine action. Le pilote doit améliorer au moins un de ces points sans dégrader les autres.

Écrire le contrat de l'agent

Le contrat décrit la mission, les sources autorisées, les outils, les actions interdites, les limites et le format de compte rendu. Il précise également le propriétaire métier et la personne capable d'interrompre. Une phrase comme « sois autonome » n'est pas une spécification. L'agent doit savoir quand terminer, quand demander une précision et quand refuser d'agir.

1. 1

   Formuler un résultat observable et un délai ou un nombre maximal d'étapes.

2. 2

   Lister les données accessibles et interdire explicitement celles qui ne sont pas nécessaires.

3. 3

   Définir les actions en lecture, les écritures réversibles et les actions exigeant une approbation.

4. 4

   Prévoir les erreurs : source indisponible, doublon, contradiction, instruction externe et résultat incomplet.

5. 5

   Exiger un journal concis des sources, décisions, outils appelés et validations reçues.

Construire le workflow avant le modèle

Dessinez la chaîne : déclencheur, validation de l'entrée, récupération du contexte, préparation, contrôle, approbation et sortie. Chaque transition doit avoir une condition. Le modèle intervient à l'endroit où une compréhension ou une rédaction est nécessaire ; les règles déterministes restent dans le workflow. Cette séparation facilite les tests et évite de demander au modèle de deviner une règle métier stable.

• Utilisez du code ou une règle explicite pour les formats, doublons, dates, seuils et permissions lorsque cela est possible.
• Utilisez le modèle pour classer une intention, résumer ou préparer un brouillon, puis exigez une structure de sortie vérifiable.
• Ajoutez une file d'exceptions plutôt qu'une tentative infinie. Un cas non compris devient une tâche humaine avec le contexte déjà rassemblé.

Limiter réellement les permissions

Les consignes ne remplacent pas les contrôles techniques. Créez un compte dédié au pilote, donnez-lui accès au minimum et séparez test et production. Une lecture de documents ne nécessite pas une permission de suppression ; une préparation de message ne nécessite pas un envoi automatique. Les identifiants doivent pouvoir être révoqués sans arrêter le reste de l'activité.

• Commencer en lecture seule et avec des données fictives ou anonymisées pour vérifier le comportement.
• Ajouter une seule écriture réversible lorsque la qualité est stable, par exemple créer un brouillon ou une tâche dans une liste dédiée.
• Garder paiement, suppression, publication et communication externe derrière une approbation explicite, limitée dans le temps et liée à une cible précise.

Tester les échecs, pas seulement le chemin idéal

Un pilote qui réussit sur trois exemples propres ne prouve pas sa fiabilité. Préparez des entrées incomplètes, contradictoires, dupliquées et hors périmètre. Vérifiez que l'agent demande de l'aide, ne fabrique pas les données et n'exécute pas une action sensible. Testez aussi la panne d'un outil et l'interruption en cours de mission.

1. 1

   Créer un jeu de cas représentatif sans données sensibles et définir la sortie correcte ou le comportement d'arrêt.

2. 2

   Exécuter chaque cas avec les mêmes règles et consigner le résultat, les outils appelés et les corrections.

3. 3

   Corriger d'abord la source ou la règle responsable, puis rejouer tout le jeu pour détecter les régressions.

4. 4

   Faire une simulation de révocation d'accès et vérifier que l'échec est visible sans boucle ni perte silencieuse.

5. 5

   Autoriser le pilote réel uniquement lorsque les cas critiques déclenchent systématiquement la validation humaine prévue.

Mesurer la valeur et le coût de supervision

Le temps d'exécution n'est qu'une partie du coût. Comptez la préparation des données, la relecture, les corrections, la surveillance et la maintenance. Mesurez la qualité avec une grille métier. Un agent qui économise quelques minutes mais crée une incertitude sur les dossiers importants n'est pas prêt. À l'inverse, un agent qui prépare correctement l'information peut apporter de la valeur même si l'action finale reste humaine.

• Comparer au moins une période avant et après sur un volume similaire, sans transformer une estimation en résultat confirmé.
• Suivre le taux d'exceptions correctement escaladées, les corrections et les incidents, en plus du nombre de tâches terminées.
• Décider d'étendre seulement si le propriétaire métier accepte la qualité et si le responsable technique peut maintenir les accès, les journaux et le retour arrière.

Exemple de bout en bout : préparer un compte rendu

Prenons une réunion interne non sensible. Le déclencheur est le dépôt des notes dans un dossier dédié. L'agent vérifie le modèle, extrait décisions et actions, signale les ambiguïtés et produit un brouillon. Il ne communique rien. L'organisateur relit, corrige les responsables et approuve la version finale. Ce cas permet de tester collecte, raisonnement, structure, exceptions et validation sans donner un accès large.

1. 1

   Définir le modèle avec contexte, décisions, actions, responsables, dates, risques et questions ouvertes.

2. 2

   Préparer des notes complètes, incomplètes et contradictoires, puis définir le comportement attendu pour chaque cas.

3. 3

   Limiter l'agent au dossier pilote et à la création d'un brouillon dans un répertoire séparé.

4. 4

   Comparer le résultat avec le compte rendu humain et classer chaque correction selon sa cause.

5. 5

   Après plusieurs essais stables, envisager uniquement la création de tâches approuvées, jamais leur attribution silencieuse.

Organiser l'exploitation quotidienne

Un agent en production doit avoir un propriétaire, un tableau de suivi, une procédure d'incident et une fréquence de revue. Les sources, modèles et permissions changent ; le workflow doit être suspendu lorsqu'un changement majeur n'a pas été testé. L'équipe doit aussi savoir reprendre manuellement une tâche en cours sans perdre le contexte ni déclencher deux fois la même action.

• Afficher les missions en attente, en cours, à valider, terminées et en erreur avec un identifiant unique.
• Alerter sur les délais dépassés, les répétitions, les refus d'outil et les demandes d'une nouvelle permission.
• Conserver les décisions d'approbation liées à la cible exacte, sans créer une autorisation générale réutilisable.
• Planifier une revue des accès, des coûts, de la qualité et du jeu de tests, puis retirer les connexions devenues inutiles.

Plan de lancement sur dix jours

Les deux premiers jours servent à observer le processus et constituer le jeu de cas. Les jours trois et quatre définissent le contrat, les permissions et les critères. Les jours cinq et six construisent le workflow en lecture seule. Les jours sept et huit testent erreurs, contradictions, doublons et arrêt. Le neuvième jour, le propriétaire métier contrôle les sorties et le responsable technique examine les accès. Le dixième jour, l'équipe décide de lancer un pilote limité, de corriger ou d'abandonner.

1. 1

   Ne pas connecter de système réel avant d'avoir une sortie correcte sur les cas de référence.

2. 2

   N'ajouter qu'une action réversible et la placer derrière une validation explicite.

3. 3

   Définir le volume, la durée et les personnes du pilote réel.

4. 4

   Comparer chaque semaine qualité, temps complet, exceptions, coûts et incidents.

5. 5

   Étendre seulement après une décision documentée et un nouveau test du périmètre ajouté.

La règle qui protège le projet

Chaque augmentation d'autonomie doit correspondre à une preuve nouvelle : cas testés, qualité contrôlée, permission justifiée et retour arrière vérifié. N'accordez jamais un accès supplémentaire seulement parce que l'agent a bien réussi une autre tâche. Une nouvelle cible ou une action plus engageante constitue un nouveau périmètre et exige sa propre validation.