On vous propose « de l'IA » pour automatiser quelque chose chez vous. Une relance client, un tri de mails, la saisie d'un devis. Vous n'avez aucun moyen de savoir si ce qu'on vous vend sera prévisible ou erratique, ni qui pourra le réparer dans six mois. Le débat public, lui, oppose des outils — celui-ci contre celui-là — et ne vous aide en rien.
La vraie ligne de partage est ailleurs. Elle est simple à voir une fois qu'on vous l'a montrée. Et je vais être honnête : je l'applique tous les jours sans l'avoir jamais formulée.
Le clivage n'est pas « avec ou sans IA »
Le bon couple n'est pas « automatisation classique » contre « intelligence artificielle ». Il est ailleurs : reproductible contre probabiliste.
Un flux classique décrit chaque chemin à l'avance. Si le formulaire arrive, alors on envoie ce mail et on crée cette ligne. Vous savez ce qui va se passer avant que ça se passe — et vous le saurez encore dans six mois.
Un modèle de langage ne répond pas deux fois exactement pareil. Ce n'est pas un défaut de jeunesse que la prochaine version corrigera : c'est sa nature. Il ne suit pas une règle, il produit ce qui lui semble le plus probable.
On m'objectera qu'on peut figer les réglages d'un modèle pour le stabiliser. C'est vrai — de votre côté. Mais vous ne choisissez ni la version du modèle, ni sa durée de vie. Les fournisseurs retirent régulièrement leurs modèles du service : Anthropic documente noir sur blanc que les siens passent par un statut « déprécié » puis « retiré », avec un préavis d'au moins soixante jours, et qu'au-delà de la date les appels échouent — c'est écrit dans sa documentation. Autrement dit, le composant sur lequel repose votre processus a une date de péremption, et ce n'est pas vous qui la fixez. Un « si le montant dépasse mille euros » n'a pas de date de péremption.
La conséquence pratique est celle qui devrait vous intéresser. Quand un flux prévisible rencontre un cas non prévu, il casse franchement. C'est moche, c'est visible, c'est daté, c'est réparable. Quand un système probabiliste rencontre le même cas, il produit quelque chose de plausible. Personne ne s'alarme. Le devis part avec la mauvaise remise et vous l'apprenez par le client.
C'est toute la différence entre une panne et une dérive. La panne est la bonne nouvelle.
Ce que je fais vraiment — et la règle que je n'avais pas nommée
Je fais tourner les deux mondes en parallèle, tous les jours.
D'un côté, une douzaine de flux visuels : ma veille hebdomadaire, mes envois automatiques, la surveillance de mes serveurs, mes sauvegardes. De l'autre, plusieurs applications que j'ai construites en écrivant du code avec un assistant IA — un back-office interne, un outil de gestion pour mon propre usage.
Je n'avais jamais réfléchi à ce qui départageait les deux. Ça s'était fait tout seul, arbitrage après arbitrage. Quand j'ai fini par regarder, la ligne était là, toujours au même endroit.
En flux visuel : ce qui est répétable à l'identique, ce qui doit tourner sans moi — y compris la nuit — et ce dont je veux pouvoir consulter l'historique pour savoir quand ça s'est mal passé, et pourquoi. En code : ce dont la logique est entièrement sur mesure, ce qui demande une interface, et ce qu'aucun assemblage existant ne couvrait.
Dit comme ça, ça ressemble à une question d'outil. Ça n'en est pas une.
La frontière ne sépare pas deux outils : elle passe à l'intérieur du même système
Voilà ce que le débat rate complètement. En pratique, on ne choisit pas un camp. On met du probabiliste à l'intérieur d'une structure prévisible.
Trois exemples pris chez moi.
Une carte de visite photographiée : un modèle de vision lit l'image et en sort un nom, un téléphone, une société. C'est du probabiliste — il peut se tromper sur un caractère. Mais ce n'est pas lui qui décide quoi en faire : un flux fixe vérifie si ce contact existe déjà, et le crée ou le fusionne selon une règle écrite.
Ma veille : un modèle note chaque article de 0 à 100 selon son utilité pour mon activité. C'est un jugement, donc du probabiliste. La sélection, elle, ne l'est pas : tout ce qui passe sous 60 est écarté, et il ne reste que les dix meilleurs. Toujours. Même une semaine faste.
Mes enregistrements de réunion : un modèle transcrit et résume. Mais c'est le nombre de voix détectées qui décide si le résultat devient un mémo ou un compte-rendu — pas le modèle.
Ce motif n'a rien de propre à mon métier. Prenez le tri des demandes qui arrivent chez vous : un modèle lit le message et le classe — devis, réclamation, question technique. C'est du jugement, il peut se tromper. Mais qui reçoit la demande, et sous quel délai elle doit être traitée, reste une règle que vous avez écrite. Le jour où le classement se trompe, la réclamation part au mauvais service — pas dans le vide.
Le motif est le même partout, et il tient en une phrase : le modèle remplit une case, il ne choisit jamais le chemin.
C'est ce qui rend un système utilisable en entreprise. Le modèle apporte ce qu'aucune règle ne sait faire — lire une image, juger un texte, résumer une conversation. La structure, elle, garantit que la suite est identique à chaque fois. Et le jour où le modèle se trompe, vous savez exactement dans quelle case, sans avoir à deviner ce qui s'est passé dans sa tête.
Une précision honnête, parce que l'objection viendrait sinon : on peut confier le chemin lui-même à un modèle. La technologie le permet, des agents décident aujourd'hui quel outil appeler et dans quel ordre, et j'en fais tourner pour explorer et pour construire. Ce n'est donc pas une loi de la nature. C'est un choix : je ne le fais pas là où une erreur coûte de l'argent, engage un client, ou devra s'expliquer six mois plus tard.
Les trois questions à poser à qui vous vend « de l'IA »
Vous n'avez pas besoin d'être technique pour vous défendre. Vous avez besoin de trois questions.
1. Qui décide — le modèle, ou une règle ? Demandez qu'on vous trace la frontière sur le schéma. Si votre interlocuteur ne sait pas où elle passe dans ce qu'il vous propose, c'est qu'elle ne passe nulle part — et vous venez d'apprendre l'essentiel.
2. Qui pourra maintenir ça quand vous ne serez pas là ? Le coût réel d'un outil n'est pas son prix, c'est son coût de transmission. Un flux visuel se reprend par quelqu'un de votre équipe qui n'est pas développeur : il voit les branches, il comprend, il modifie. Du code généré par un assistant exige un niveau que la démonstration ne laisse pas deviner — c'est même le piège de ces outils, ils ont l'air simples précisément parce que quelqu'un d'autre écrit le code. Notez au passage que le modèle économique s'inverse : dans un cas vous payez l'usage, dans l'autre vous payez la construction, puis l'hébergement, puis la surveillance.
3. Quand ça casse, vous le voyez, ou vous l'apprenez ? Ici, je dois être honnête contre mon propre camp : un système parfaitement déterministe peut mentir avec une régularité parfaite. J'ai eu un script de sauvegarde qui affichait « aucune erreur » pendant trois semaines sans rien sauvegarder — la ligne censée détecter l'échec ne pouvait pas fonctionner, par construction. Le déterminisme garantit la reproductibilité, pas la vérité. Ce qui protège, ce n'est pas le type d'outil : c'est d'aller vérifier à l'arrivée plutôt que de croire le rapport.
Où placer la frontière
Ceci n'est pas un plaidoyer contre l'IA. J'en fais tourner tous les jours, et les exemples plus haut seraient impossibles sans elle.
La question n'est jamais « IA ou pas ». Elle est : où passe la frontière, et qui l'a tracée ? Un prestataire qui sait vous répondre travaille sérieusement. Un prestataire qui vous vend « une IA qui gère tout » vous vend un système dont personne, lui compris, ne pourra expliquer une décision dans six mois.
C'est cette ligne que je prépare à tracer avec les dirigeants que j'accompagnerai : décider, pour chaque étape d'un processus, ce qui relève du jugement et ce qui relève de la règle. Ce n'est pas un arbitrage technique. C'est un arbitrage de gestion — et il vous appartient.