IA ou automatisation : comment choisir

Publié le 8 septembre 2026 · David Sylvester · Lecture : 9 min.

Une responsable de gestion m'a dit récemment qu'elle avait testé un assistant IA grand public sur ses calculs de marge. Trois essais, trois résultats faux. Sa conclusion tenait en une phrase : l'IA n'est pas fiable.

Elle avait raison sur le constat et tort sur la cause. Le problème n'était pas l'outil. Le problème était qu'on lui avait vendu, collectivement, l'idée qu'un modèle de langage est une machine à tout faire.

Cet article répond aux questions que les dirigeants de PME me posent le plus souvent avant de signer quoi que ce soit.

Est-ce que toutes les tâches répétitives relèvent de l'IA ?

Non. Et c'est la confusion la plus coûteuse du moment.

Depuis deux ans, le mot IA a absorbé tout le champ de l'automatisation. Un script qui recopie des lignes d'un fichier vers un autre, une macro qui compare deux extractions, un traitement qui vérifie qu'aucune prestation n'a été oubliée à la facturation : tout ça existe depuis vingt ans, ça fonctionne parfaitement, et ça n'a jamais eu besoin d'un modèle de langage.

Ce qui a changé, ce n'est pas la faisabilité. C'est le coût de construction. Ce qui demandait un développeur pendant trois semaines se construit aujourd'hui en quelques jours. Le gain est réel, mais il se situe dans la vitesse de fabrication de l'outil, pas dans la nature de l'outil.

Quand un prestataire te propose de l'IA sur une tâche de recoupement de chiffres, deux choses sont possibles. Soit il n'a pas encore regardé ton besoin. Soit il te vend le mot parce que le mot se vend.

Quelle est la différence concrète entre déterministe et probabiliste ?

Un traitement déterministe donne toujours le même résultat pour la même entrée. Tu lances le calcul dix fois, tu obtiens dix fois le même chiffre. Si le résultat est faux, il est faux de la même manière à chaque fois, donc tu peux le corriger définitivement.

Un modèle de langage est probabiliste. Il produit la réponse la plus plausible compte tenu de ce qu'il a appris. La plupart du temps, la plus plausible est aussi la bonne. Mais la plausibilité n'est pas l'exactitude, et le modèle n'a aucun moyen de te dire dans quel cas tu es.

C'est une propriété de conception, pas un défaut de jeunesse. Aucune version future ne la fera disparaître, parce que c'est précisément ce qui permet au modèle de traiter du langage, du contexte, de l'ambiguïté.

Donc la question n'est jamais « est-ce que l'IA est fiable ». La question est : est-ce que ma tâche tolère une réponse plausible, ou exige-t-elle une réponse exacte ?

Un calcul de marge doit être exact. Un brouillon de réponse client doit être pertinent. Ce ne sont pas les mêmes exigences, donc ce ne sont pas les mêmes outils.

Comment savoir de quel côté tombe ma tâche ?

Quatre questions suffisent dans la grande majorité des cas.

La règle est-elle écrivable ?

Si tu peux expliquer à un stagiaire, en une page, exactement quoi faire dans tous les cas, la règle est écrivable. Elle se code. Croiser des heures prestées avec de la facturation, détecter une ligne présente d'un côté et absente de l'autre : c'est écrivable.

Le résultat doit-il être vérifiable au chiffre près ?

Si une erreur d'un pour cent est un problème, tu es du côté déterministe. Une facture, une marge, un stock, un décompte d'heures : ces objets ne supportent pas l'approximation.

L'entrée est-elle structurée ?

Un fichier Excel, un export comptable, une base de données : c'est structuré. Un mail de client, un PDF scanné, un compte rendu de chantier écrit à la main : ce ne l'est pas. Plus l'entrée est désordonnée, plus un modèle apporte de la valeur, parce qu'il sait interpréter ce qu'un script ne sait que lire.

Le jugement fait-il partie du travail ?

Résumer, classer, prioriser, rédiger, reformuler : ce sont des tâches de jugement. Il n'existe pas une seule bonne réponse, il existe des réponses acceptables. C'est exactement le terrain d'un modèle.

En pratique, la plupart des chantiers PME que je vois sont hybrides. Le calcul est déterministe, la mise en forme et le commentaire peuvent être assistés. La compétence consiste à découper au bon endroit, pas à choisir un camp.

À quoi ressemble un découpage correct en pratique ?

La grille ne sert à rien tant qu'on ne l'applique pas à des tâches précises. Voici cinq tâches que je rencontre dans à peu près toutes les PME, et de quel côté elles tombent.

Vérifier que tout le travail réalisé a bien été facturé. Déterministe. Les règles sont écrivables, les entrées sont structurées, le résultat doit être exact. Un traitement lit les fichiers, applique les règles, sort une liste d'anomalies. Aucune IA nécessaire, et c'est souvent la tâche au meilleur rapport gain sur risque, parce qu'une prestation oubliée est une perte sèche.

Consolider un tableau de bord mensuel à partir de plusieurs exports. Déterministe aussi. Ce sont des agrégations et des jointures. Le vrai travail consiste à fiabiliser les cas particuliers une bonne fois, pas à interpréter quoi que ce soit.

Trier les demandes entrantes et les router vers la bonne personne. Probabiliste. L'entrée est du langage libre, écrit par des humains pressés, sans format. Aucun script ne tient la distance. Un modèle fait ça très bien, et l'erreur y est peu coûteuse puisqu'un humain reçoit quand même la demande.

Extraire des informations d'un document non structuré — un bon de commande scanné, un courrier, un compte rendu. Probabiliste sur la lecture, déterministe sur la vérification. Le modèle propose les valeurs, un contrôle automatique vérifie la cohérence, un humain valide ce qui sort du cadre. C'est le cas hybride typique, et c'est là que le découpage rapporte le plus.

Interpréter les résultats et décider quoi faire. Humain. Pourquoi cette activité décroche ce trimestre, faut-il investir ou arrêter, quoi présenter à l'assemblée des associés : ce n'est ni du calcul ni du langage, c'est du métier. C'est précisément ce que les gens n'ont plus le temps de faire quand ils passent leurs journées à fiabiliser des chiffres.

L'ordre compte. On fiabilise d'abord, on augmente ensuite. Poser de l'IA au-dessus de données non fiabilisées ne fait qu'accélérer la production de chiffres dont personne n'est sûr.

Qu'est-ce que ça change sur le coût réel ?

Beaucoup, et pas dans le sens que la plupart imaginent.

Un traitement déterministe se paie une fois, à la construction. Ensuite il tourne. Le coût marginal d'une exécution est proche de zéro. Tu peux le lancer trois fois par jour pendant cinq ans sans que la facture bouge.

Un traitement basé sur un modèle se paie à l'usage, à chaque exécution, pour toujours. Ce n'est pas un problème en soi : sur des tâches où le modèle apporte quelque chose, ça vaut largement son prix. Ça devient un problème quand on paie ce coût récurrent pour une tâche qu'un script aurait faite gratuitement.

Il y a un deuxième coût, moins visible. Un système dont on ne peut pas prouver l'exactitude génère du travail de vérification. Si ton équipe doit recontrôler les chiffres sortis par l'outil, tu n'as pas automatisé la tâche. Tu l'as déplacée, et tu paies deux fois.

Un troisième coût mérite d'être nommé : celui de l'outil qui n'est jamais mis en production. J'ai vu plusieurs fois un logiciel parfaitement fonctionnel rester inactif pendant des mois. Licences à arbitrer, configuration à finir, personne pour porter le sujet en interne. Le blocage n'était pas technique. Il ne l'est presque jamais. Un système simple que quelqu'un utilise vaut mieux qu'un système riche que personne ne lance.

C'est la question que je pose avant de chiffrer quoi que ce soit : combien de temps ce système fera-t-il vraiment gagner, une fois déduit le temps de vérification qu'il crée ? Un projet qui se rembourse tout juste est un projet fragile. Il suffit d'un retard ou d'un imprévu pour qu'il passe en perte, et c'est à ce moment-là que l'outil est abandonné.

Qu'est-ce que ça change sur mes données et sur la conformité ?

C'est l'argument le moins discuté et souvent le plus décisif.

Un traitement déterministe sur tes fichiers tourne là où tu décides. Sur ton serveur, sur ton poste, dans ton réseau. Aucune donnée ne sort. Il n'y a pas de sous-traitant à déclarer, pas de transfert à documenter, pas de clause à négocier.

Dès qu'un modèle hébergé chez un tiers entre dans la chaîne, la question change de nature. Il faut savoir quelles données lui sont envoyées, où elles sont traitées, combien de temps elles sont conservées, et si elles servent à autre chose. Ce n'est pas rédhibitoire, c'est simplement un dossier à monter. Sur des données sensibles, des données de santé ou des données de personnel, ce dossier devient lourd.

Beaucoup de PME wallonnes découvrent ça après coup, quand un client ou un auditeur pose la question. Choisir le déterministe quand il suffit, ce n'est pas de la prudence excessive. C'est éviter de créer une obligation dont tu n'avais pas besoin.

Où l'IA est-elle vraiment irremplaçable dans une PME ?

Là où l'entrée est du langage ou du désordre.

• Trier des demandes entrantes et les router vers la bonne personne.
• Extraire des informations d'un document non structuré — un bon de commande scanné, un compte rendu, un courrier.
• Préparer un brouillon de réponse à partir d'un historique client.
• Résumer une réunion en points d'action.
• Reformuler un texte technique pour un destinataire non technique.

Sur ces tâches, aucun script ne fait le travail, et l'écart de performance est spectaculaire.

Un point de méthode que je maintiens partout : sur tout ce qui sort de l'entreprise, la machine prépare et l'humain envoie. Je ne recommande pas l'envoi automatique de mails clients. Le gain de temps est réel sur la préparation, et il ne justifie pas de laisser partir un message que personne n'a relu.

Comment lire un devis qui met de l'IA partout ?

Trois signaux à vérifier.

Le premier : le devis distingue-t-il ce qui est calculé de ce qui est interprété ? Si tout est présenté comme de l'IA, c'est que le découpage n'a pas été fait. Il le sera pendant le projet, à tes frais.

Le deuxième : que se passe-t-il si tu arrêtes de payer ? Un traitement déterministe dont tu possèdes le code continue de tourner. Un système entièrement dépendant d'une licence ou d'un abonnement s'arrête. Ce n'est pas un défaut, mais il faut le savoir avant, pas après.

Le troisième : le prestataire assume-t-il ses zones d'incertitude ? Un devis qui ne comporte aucune inconnue sur un système qui n'a jamais été construit chez toi est un devis qui n'a pas été réfléchi. Les inconnues existent toujours. Ce qui distingue les prestataires, c'est qu'ils les nomment ou qu'ils les cachent.

Par où commencer cette semaine ?

Prends la tâche mensuelle qui te coûte le plus de temps et où le résultat doit être exact au centime. Écris en une page ce que fait la personne qui s'en occupe, dans l'ordre, avec les cas particuliers.

Si cette page tient, tu as un candidat pour de l'automatisation déterministe. C'est presque toujours le chantier au meilleur rapport gain sur risque dans une PME, et c'est presque jamais celui qu'on te propose, parce qu'il se vend moins bien.

Si cette page ne tient pas, si le travail dépend du jugement de la personne à chaque étape, tu as un candidat pour de l'assistance IA. Là, le bon réflexe est de commencer petit, sur une tâche à faible enjeu, et de mesurer.