La bonne question n’est pas « faut-il de l’IA dans ce processus ? », mais « qui doit exécuter chaque étape ? ». Une règle stable et calculable relève du code ; la lecture d’un texte, d’un document ou d’une variation difficile à anticiper relève de l’IA ; une décision qui engage l’entreprise, un cas hors règle ou une responsabilité reste à un humain. Un processus fiable combine presque toujours les trois, et la répartition se décide étape par étape, pas une fois pour tout le processus.
Trois exécutants, trois natures différentes
Avant de répartir, il faut savoir ce que chacun fait bien.
Le code et l’automatisation classique sont déterministes : la même entrée produit toujours la même sortie. Un calcul de prix, une vérification de seuil, un transfert de fichier ou une écriture dans un ERP ne varient pas d’une exécution à l’autre. C’est leur force : on peut tester, expliquer et auditer. C’est aussi leur limite : face à une entrée qui ne ressemble pas à ce qui était prévu (un PDF mis en page autrement, une formulation inattendue), une règle codée casse ou se trompe en silence.
L’IA, et en particulier les modèles de langage, est probabiliste. Elle sait lire un e-mail rédigé librement, extraire les informations d’un document dont le format change, classer une demande ou rédiger un brouillon. Elle absorbe la variation que le code ne sait pas gérer. En contrepartie, sa sortie n’est pas garantie : deux exécutions peuvent différer, et une erreur peut avoir l’air parfaitement plausible.
L’humain apporte le jugement, le contexte que personne n’a écrit et, surtout, la responsabilité. Une remise exceptionnelle, un litige, un engagement contractuel ou un cas jamais vu relèvent de quelqu’un qui peut en répondre. L’humain est en revanche l’exécutant le plus coûteux et le moins régulier sur les tâches répétitives : l’attention baisse avec le volume.
La grille de décision
Pour chaque étape du processus, cinq critères suffisent à orienter le choix. Aucun ne décide seul ; c’est leur combinaison qui compte.
| Critère | Pousse vers le code | Pousse vers l’IA | Pousse vers l’humain |
|---|---|---|---|
| Variabilité des entrées | Entrées structurées, format fixe (formulaire, fichier normé, API) | Texte libre, documents hétérogènes, formulations changeantes | Situation inédite, information manquante ou contradictoire |
| Coût d’une erreur | Faible ou moyen, et l’erreur serait systématique donc repérable | Faible à moyen, à condition qu’un contrôle suive | Élevé : engagement financier, contractuel, relation client sensible |
| Besoin d’explicabilité | Il faut pouvoir justifier le résultat par une règle écrite | Une justification par la source suffit (« extrait de tel passage ») | La décision doit être assumée par une personne identifiée |
| Volume | Élevé et régulier | Élevé, avec une variété que des règles ne couvrent pas | Faible : quelques cas par semaine ou par mois |
| Traçabilité | La règle et sa version suffisent à reconstituer le résultat | Il faut conserver l’entrée, la sortie et la version du modèle ou des instructions | Il faut savoir qui a validé, quand, et sur quelle base |
Deux questions complémentaires aident à trancher les cas limites :
- Peut-on écrire la règle ? Si un responsable métier sait formuler la règle complète, exceptions comprises, c’est du code. S’il répond « ça dépend, il faut regarder », c’est soit de l’IA (si le jugement porte sur la lecture), soit de l’humain (si le jugement porte sur la décision).
- Que se passe-t-il si l’étape se trompe sans que personne ne le voie ? Si la réponse est « on perd de l’argent ou un client », l’étape ne peut pas être confiée à l’IA sans contrôle en aval.
Un même processus, étape par étape
Prenons un exemple illustratif : une entreprise de distribution B2B reçoit chaque jour des demandes de devis. Elles arrivent par e-mail, parfois en pièce jointe PDF, parfois via un formulaire. Aujourd’hui, un chargé d’ADV lit chaque demande, retrouve le client, identifie les articles, calcule le prix, vérifie le stock et rédige la réponse.
| Étape | Exécutant | Pourquoi |
|---|---|---|
| 1. Réception et horodatage de la demande | Code | Entrée technique stable : capter l’e-mail, enregistrer la pièce jointe, créer un dossier. |
| 2. Lecture et extraction (client, articles, quantités, délai, conditions particulières) | IA | Texte libre et documents hétérogènes : aucune règle ne couvre toutes les formulations. |
| 3. Identification du client dans le CRM ou l’ERP | Code, puis humain si échec | Correspondance par adresse e-mail, SIREN ou numéro de compte. Si aucune correspondance fiable, un humain tranche. |
| 4. Rapprochement des désignations avec le catalogue | IA, vérifiée par le code | L’IA propose une référence pour « vis inox M8 x 40 tête hexagonale » ; le code vérifie que la référence existe et qu’elle est vendable. |
| 5. Calcul du prix (tarif, remise client, paliers de quantité, port) | Code | Règle calculable et à justifier : aucune raison de la confier à un modèle probabiliste. |
| 6. Contrôles (marge minimale, stock, délai réalisable) | Code | Seuils explicites, résultats binaires, faciles à journaliser. |
| 7. Cas hors règle (marge sous le seuil, remise non standard, nouveau client sur un montant élevé, demande technique spécifique) | Humain | Décision qui engage l’entreprise et qu’une personne doit pouvoir assumer. |
| 8. Rédaction du message d’accompagnement | IA, validée par un humain selon le cas | Rédaction adaptée au ton de la demande ; relecture obligatoire au-delà d’un montant ou pour certains clients. |
| 9. Envoi, enregistrement dans l’ERP, relance planifiée | Code | Actions répétitives et traçables. |
Trois enseignements ressortent de ce déroulé. D’abord, l’IA n’occupe que deux ou trois étapes, celles où il faut lire ou écrire. Ensuite, chaque sortie de l’IA est suivie d’une vérification par le code ou par un humain : l’IA ne transmet jamais directement un résultat à une étape engageante. Enfin, l’humain n’intervient plus sur toutes les demandes, mais sur celles qui le justifient ; son rôle passe de la saisie à la décision.
Ce découpage n’est pas universel. Si les demandes arrivaient toutes par un formulaire structuré ou par EDI, l’étape 2 redeviendrait du code et l’IA n’aurait probablement aucune place dans le processus. C’est un bon signe : la grille sert aussi à conclure qu’on n’a pas besoin d’IA.
Pourquoi combiner probabiliste et déterministe
La combinaison n’est pas un compromis, c’est ce qui rend le système fiable. L’IA traite la variation en amont et produit une sortie structurée (des champs, pas un paragraphe). Le code prend le relais sur cette sortie : il vérifie, calcule, applique les règles et bloque ce qui ne passe pas. L’humain reçoit les cas bloqués, avec le contexte nécessaire pour décider vite.
Ce schéma, « l’IA interprète, le code vérifie, l’humain tranche », a deux avantages. Il limite la zone où une erreur probabiliste peut se glisser : le prix, la marge et l’écriture comptable ne dépendent jamais du modèle. Et il rend le système explicable : pour chaque devis, on peut dire ce que l’IA a lu, quelles règles ont été appliquées et qui a validé l’exception.
À l’inverse, deux dérives reviennent souvent. Tout confier à l’IA, y compris les calculs et les contrôles, parce que « le modèle sait le faire » : le résultat est juste la plupart du temps et faux sans prévenir le reste du temps. Et tout coder, y compris la lecture de documents variables, au prix de règles d’extraction fragiles qui cassent à chaque changement de mise en page d’un fournisseur ou d’un client. C’est précisément cet arbitrage qui occupe l’étape d’architecture de notre méthode, entre formalisation et construction.
Comment contrôler les sorties de l’IA
Confier une étape à l’IA suppose d’accepter qu’elle se trompe parfois, et donc d’organiser la détection. Quatre dispositifs se complètent.
Un jeu de test construit sur des cas réels
Avant la mise en service, on rassemble un échantillon de demandes réelles, anonymisées si nécessaire, avec le résultat attendu pour chacune. L’échantillon doit inclure les cas difficiles : pièces jointes illisibles, demandes multiples dans un même e-mail, références obsolètes, formulations ambiguës. On mesure le taux de bonnes extractions champ par champ, puis on rejoue ce jeu de test à chaque changement de modèle, d’instructions ou de règles. Sans jeu de test, on ne sait pas si une modification améliore ou dégrade le système.
Des seuils et des contrôles de cohérence
Chaque sortie de l’IA passe par des contrôles déterministes : champs obligatoires présents, quantités positives, référence existante dans le catalogue, client connu, total recalculé par le code. Lorsque l’IA fournit un niveau de confiance, il peut servir à orienter les cas vers une revue humaine, mais il ne remplace pas ces contrôles : un modèle peut être confiant et se tromper. Les seuils se règlent à partir du jeu de test, en arbitrant entre le nombre de cas envoyés en revue et le risque d’erreur non détectée.
Une validation humaine ciblée et outillée
Valider toutes les sorties n’est pas une bonne protection : au bout de quelques centaines de validations identiques, la vigilance baisse et l’on finit par approuver sans lire. Mieux vaut réserver la validation aux cas qui la méritent (montant, client, écart détecté) et présenter au valideur la source, la proposition et ce qui a déclenché la revue. Une validation doit prendre quelques secondes quand tout est cohérent, et attirer l’œil sur ce qui ne l’est pas.
Une journalisation complète
Pour chaque exécution, on conserve l’entrée, la sortie de l’IA, la version du modèle et des instructions, les contrôles appliqués et la décision humaine éventuelle. Ce journal sert à trois choses : expliquer un résultat contesté, repérer une dérive (un type de document qui se met à échouer plus souvent) et enrichir le jeu de test avec les corrections réelles. C’est aussi ce qui distingue un prototype convaincant d’un système qu’on peut exploiter durablement, un passage que nous détaillons dans ce qui sépare un prototype IA d’un processus en production. Les questions de données et d’hébergement associées sont traitées dans notre page sécurité et données.
Quand cette grille ne suffit pas
La grille suppose que le processus est connu. Si personne ne sait décrire les étapes, les exceptions et les critères de décision réellement utilisés, la répartition sera arbitraire : il faut d’abord observer et formaliser le processus, ce que fait une cartographie de processus.
Elle ne dit pas non plus s’il faut construire. Si un module de votre ERP ou un logiciel du marché couvre déjà le processus avec des entrées structurées, l’acheter et le paramétrer sera souvent plus simple qu’un système sur mesure, et un prestataire comme nous n’est alors pas nécessaire. De même, un processus à très faible volume, avec quelques cas par mois, gagne rarement à être automatisé : un bon modèle de document et une liste de contrôle suffisent.
Pour aller plus loin
Si vous avez déjà identifié le processus et que la répartition entre code, IA et validation humaine est la prochaine question, c’est l’objet de notre offre d’implémentation de processus : architecture, construction, tests sur vos cas réels et mise en service.