Si toutes les entreprises tentent généralement de se lancer dans des projets d’IA générative, pas toujours simple de produire avec elle un impact mesurable sur le chiffre d’affaires et/ou les opérations.

Le plus souvent, ces échecs proviennent d’une mauvaise définition des besoins métier en amont, avec parfois aussi une portée de projet mal cadrée… bien avant les limites techniques des modèles eux-mêmes !

Finalement, on observe un point commun sur la plupart des projets qui échouent : ils partent d’un processus entier (l’IA pour le service client, l’IA pour la finance, etc.) plutôt que d’une action précise à l’intérieur de ce processus.

Dans les faits, le bon niveau de granularité ne se trouve pas dans vos métiers ou dans vos processus, mais dans l’action elle-même : explications.

Pourquoi le processus entier n’est pas le bon point de départ pour votre projet IA

Bien qu’elles soient aujourd’hui très avancées, les technologies actuelles ne peuvent généralement pas automatiser les métiers dans leur intégralité. En revanche, dans chacun de ces métiers, une part importante des tâches du quotidien reste bel et bien automatisable, à condition de les prendre une par une.

Quand il s’agit d’automatiser un processus de traitement de factures, par exemple, on doit combiner :

De l’extraction de données (délégable) ;
De la vérification de cohérence (délégable) ;
Mais aussi parfois l’arbitrage d’un litige fournisseur atypique (pas délégable, ou pas encore).

Si vous traitez ce processus comme un bloc unique, vous appliquez la même solution à des tâches qui n’ont ni la même structure, ni le même niveau de risque en cas d’erreur.

4 étapes pour distinguer une action délégable à l’IA

Avant de choisir un outil et une approche technologique, il faut savoir précisément quelle tâche confier.

Pour qu’elle puisse être déléguée, une action doit réunir ces caractéristiques :

Une entrée structurée ou stable. La donnée en entrée suit un format récurrent (facture, ticket de support, contrat type).
Une fréquence élevée. L’action se répète suffisamment souvent pour justifier l’investissement de mise en place. Une tâche rare, même pénible, se rentabilise mal.
Un résultat vérifiable. On peut objectivement dire si la sortie est correcte ou non, sans y consacrer plus de temps qu’à la réaliser soi-même.
Une marge de jugement limitée. L’action ne demande pas d’arbitrage sur des enjeux contradictoires (juridique contre commercial, coût contre délai).

Une fois l’action isolée, le bon outil n’est pas toujours un chatbot généraliste

Une fois l’action délimitée, la question du modèle se pose différemment. Les actions cadrées et répétitives comme l’extraction, le classement ou la réponse sur une base documentaire sont souvent mieux traitées par un modèle spécialisé (SLM), entraîné sur le vocabulaire et les procédures internes, et exécuté sur du matériel déjà en place.

Vous pouvez aussi tirer profit d’un grand modèle généraliste (LLM), mais plutôt sur les tâches ouvertes : raisonnement inédit, rédaction complexe, exploration d’un problème mal défini… Précisément les actions qui, dans la méthode ci-dessus, ne remplissent pas les 4 critères de délégation.

Ce choix n’est pas qu’une question de performance : un SLM hébergé en France coûte généralement moins cher à l’usage qu’un abonnement LLM facturé à la requête, et il n’expose pas vos données à l’infrastructure d’un fournisseur tiers à chaque appel.

Déléguer une action ne veut pas dire arrêter de la superviser

Une action déléguée à un agent IA reste une action dont la DSI est responsable. Très concrètement, vous devez pouvoir tracer ce que l’agent a traité, mais aussi disposer d’un point d’escalade clair vers un humain dès que le cas sort du périmètre défini… sans oublier un audit régulier des sorties produites. Notre article sur le management des agents IA détaille ce cadre de gouvernance, pensé comme celui d’un collaborateur qu’on intègre, pas d’un logiciel qu’on installe.

Ce point de vigilance compte aussi côté humain : quand vous déléguez une action, vous ne devez pas vider l’équipe de la compétence nécessaire pour vérifier ce que produit l’agent. C’est tout l’enjeu de la dette cognitive, quand un collaborateur ne sait plus repérer une extraction fausse parce qu’il n’a jamais fait l’exercice lui-même et qu’il se trouve en incapacité de superviser l’agent.

La productivité que l’IA apporte réellement à un processus ne vient pas de l’ampleur du déploiement, mais de la précision avec laquelle chaque action a été isolée avant d’y appliquer la bonne solution.

Comité de rédaction Sigma