Chaque entreprise avec laquelle nous travaillons a une liste de processus qui « devraient être automatisés ». La liste est généralement longue, ambitieuse et totalement inutile pour décider par où commencer. Cadrer le premier projet d’agent IA est la décision la plus déterminante dans le parcours d’une entreprise vers les agents — réussissez-le, et vous créez une dynamique ; ratez-le, et vous confirmez les craintes de chaque sceptique.
L’objectif du premier projet n’est pas de résoudre votre plus gros problème. C’est de prouver que les agents fonctionnent dans votre environnement, avec vos systèmes, vos données et votre équipe. Tout le reste en découle.
Le piège du cadrage
La plupart des organisations cadrent leur premier projet d’agent de l’une des deux manières suivantes, toutes deux incorrectes.
Trop ambitieux. « Automatisons l’intégralité du parcours d’onboarding client. » Ça sonne bien en comité de pilotage, mais ça touche six systèmes, trois équipes et deux cadres réglementaires. Douze mois plus tard, le projet est toujours en développement, le budget est dépassé, et personne ne peut montrer un résultat.
Trop trivial. « Faisons répondre l’agent aux FAQ de notre base de connaissances. » Ça sort en deux semaines, et personne ne s’en soucie. Ça ne change aucun workflow, ne fait gagner aucun temps significatif, et ne démontre rien qu’une barre de recherche ne pourrait faire. L’organisation conclut que les agents sont un jouet.
Le juste milieu est un projet suffisamment ciblé pour aboutir rapidement, mais suffisamment impactant pour que les gens le remarquent.
Cinq critères pour un bon premier projet
Nous évaluons les processus candidats selon cinq critères. Un bon premier projet en remplit au moins quatre.
1. Fort volume, faibles enjeux
Vous voulez un processus qui s’exécute assez fréquemment pour générer un impact visible, mais où les erreurs individuelles ne sont pas catastrophiques. Traiter 200 factures par semaine ? Bon candidat. Approuver des déclarations réglementaires ? Pas pour votre premier projet.
Le volume compte parce qu’il fournit les données pour évaluer rapidement la performance de l’agent. Si le processus s’exécute deux fois par mois, vous ne saurez pas si l’agent fonctionne avant six mois. S’il s’exécute 50 fois par jour, vous le saurez en une semaine.
Les faibles enjeux comptent parce que le premier projet a besoin de marge pour apprendre. L’agent fera des erreurs — tous les agents en font dans les premières semaines. Ces erreurs doivent être corrigeables, pas fatales pour une carrière.
2. Entrées et sorties claires
Le processus doit avoir un déclencheur bien défini et un résultat bien défini. Un email arrive, et un ticket est créé avec les bons champs remplis. Un document est chargé, et les données pertinentes sont extraites dans un format structuré. Un formulaire est soumis, et la bonne équipe est notifiée avec le bon contexte.
Évitez les processus où la définition de « terminé » est subjective ou nécessite un jugement de domaine approfondi pour être évaluée. Vous voulez pouvoir regarder le résultat de l’agent et déterminer rapidement : correct ou incorrect.
3. Une douleur existante que les gens ressentent
Le meilleur premier projet est celui où l’équipe sait déjà que le processus est cassé. Ils s’en sont plaints. Ils ont demandé de l’aide. Ils y passent des heures dont ils savent qu’elles pourraient être mieux employées ailleurs.
C’est important pour deux raisons. Premièrement, le business case est évident — vous n’avez pas besoin d’un slide deck pour expliquer pourquoi automatiser quelque chose que tout le monde déteste est utile. Deuxièmement, vous avez des champions intégrés. Les personnes qui subissent le processus manuel soutiendront la réussite de l’agent.
Si vous devez convaincre les gens qu’un processus mérite d’être automatisé, ce n’est pas le bon premier projet.
4. Un système de référence unique
Le premier projet idéal lit et écrit dans un système principal — votre CRM, votre outil de ticketing, votre plateforme de gestion documentaire. Il peut consulter d’autres systèmes, mais le workflow principal vit à un seul endroit.
L’orchestration multi-systèmes est puissante, et vous y arriverez. Mais pour le premier projet, chaque intégration supplémentaire double la complexité, la surface de test et le nombre d’équipes à impliquer. Commencez avec un seul système, prouvez la valeur, puis étendez.
5. Une équipe volontaire
Vous avez besoin d’une équipe ouverte à travailler avec l’agent — pas enthousiaste (c’est un bonus), mais au moins volontaire. Une équipe échaudée par des automatisations ratées, ou politiquement opposée à l’initiative, trouvera des moyens de faire échouer n’importe quel projet quelle que soit la technologie.
Le travail de conduite du changement dont nous avons parlé dans notre article précédent prend tout son sens ici. L’équipe volontaire devient votre groupe pilote, votre source de feedback et, à terme, vos ambassadeurs internes.
Premiers projets qui fonctionnent couramment
D’après ce que nous avons vu réussir, ces schémas font systématiquement de bons premiers projets :
Tri et routage des emails. L’agent lit les emails entrants, les classe par intention et urgence, extrait les informations clés et les dirige vers la bonne équipe ou file d’attente avec un résumé structuré. Fort volume, critères de succès clairs, gain de temps immédiat pour celui qui le faisait manuellement.
Extraction de données documentaires. Factures, contrats, certificats, dossiers — l’agent lit les documents, en extrait les champs structurés et alimente votre système de référence. L’équipe examine un échantillon pour valider la qualité. Cela fonctionne particulièrement bien parce que c’est fastidieux, sujet aux erreurs quand c’est fait manuellement, et l’avant/après est mesurable.
Génération de rapports de statut. L’agent surveille un système — suivi de projets, file de support, tableau de bord de pipeline — et génère des synthèses périodiques pour les parties prenantes. Faible risque, immédiatement utile, et ça démontre la capacité de l’agent à comprendre le contexte et communiquer clairement.
Traitement des demandes internes. Demandes d’accès IT, approbations d’achats, requêtes RH — des demandes structurées qui suivent un schéma prévisible mais nécessitent actuellement qu’un humain lise, interprète et agisse. L’agent traite les cas routiniers et escalade les exceptions.
Ce qu’il faut éviter pour le premier projet
Tout ce qui est orienté client. Non pas parce que les agents ne peuvent pas le gérer, mais parce que le profil de risque est inadapté pour un premier projet. La communication externe amplifie les erreurs et élève les enjeux inutilement. Commencez en interne, construisez la confiance, puis passez à l’externe.
Tout ce qui nécessite des performances temps réel. Si le processus exige des réponses en moins d’une seconde et ne tolère pas le moindre retry, cela ajoute une couche de complexité technique qui distrait de l’objectif principal : prouver la valeur des agents.
Tout ce qui est politiquement sensible. Si le processus fait l’objet d’une guerre de territoire, d’une réorganisation en cours ou d’un audit de conformité, le projet d’agent sera pris dans des tirs croisés qui n’ont rien à voir avec les agents.
Tout ce qui nécessite de changer le processus d’abord. Si l’équipe dit « il faut standardiser notre processus avant de pouvoir l’automatiser », c’est un détour de six mois avant même que le projet d’agent ne commence. Choisissez un processus qui fonctionne aujourd’hui, même s’il est désordonné. Les agents gèrent le désordre mieux que vous ne le pensez.
Se préparer pour réussir
Une fois le projet choisi, trois éléments posent les bases du succès :
Définir les métriques de succès avant de construire. « Comment saurons-nous que ça a marché ? » doit avoir une réponse concrète avant qu’une seule ligne de code ne soit écrite. Temps gagné par semaine. Taux d’erreur comparé au traitement manuel. Pourcentage de cas traités sans escalade. Choisissez deux ou trois métriques, établissez une référence, et convenez de ce que « suffisamment bon » signifie.
Fixer un délai. Le premier projet doit montrer des résultats en quatre à six semaines. Pas un système peaufiné et entièrement autonome — un agent fonctionnel qui gère les cas courants, escalade les cas limites et démontre une amélioration mesurable. Si le périmètre ne tient pas en six semaines, il est trop large. Réduisez-le.
Planifier la passation dès le premier jour. Qui surveille l’agent après le lancement ? Qui examine les escalades ? Qui décide quand élargir le périmètre ? Ces questions semblent prématurées pendant le cadrage, mais y répondre tôt évite le syndrome du « pilote réussi que personne ne possède ».
Après le premier projet
Le premier projet est un fondement, pas une destination. Son vrai livrable n’est pas le processus automatisé — c’est la preuve que les agents fonctionnent ici, l’équipe qui sait comment travailler avec eux, et le playbook pour le projet suivant.
Le deuxième projet peut être plus ambitieux. Vous avez de l’expérience en production, des attentes calibrées et des champions internes. Le troisième projet est celui où les choses s’accélèrent — le schéma est établi, l’infrastructure est en place, et l’organisation sait à quoi s’attendre.
Mais rien de tout cela n’arrive si le premier projet n’aboutit pas. Choisissez quelque chose de ciblé, impactant et réalisable. Prouvez que ça marche. Puis grandissez à partir de là.