Introduction
On nous demande souvent si nos outils internes sont « faits avec de l'IA ». La réponse honnête : oui, l'IA est partout chez nous, et pourtant la majorité de ce qui tourne chaque jour est du code parfaitement déterministe. Ce n'est pas une contradiction. C'est une frontière qu'on trace, feature par feature, avec des règles devenues réflexes.
La question n'est jamais « IA ou pas IA ». C'est : à quel endroit précis de la chaîne l'IA apporte quelque chose qu'une règle écrite ne peut pas faire, et comment on l'encadre à cet endroit-là.
Règle 1 : le déterministe par défaut, l'IA par exception
Si une règle écrite peut faire le travail, on écrit la règle. Elle est gratuite à exécuter, reproductible, testable, et elle ne changera pas d'avis demain matin.
Deux exemples chez nous. Pour scorer nos leads, on aurait pu demander à un grand modèle « note ce prospect de 1 à 10 ». On a préféré une régression logistique entraînée chaque nuit sur nos propres appels : la probabilité affichée vient avec ses trois raisons en clair, la qualité du modèle est mesurée et stockée à chaque entraînement, et tout ça ne coûte rien à l'inférence. Un modèle plus sophistiqué est le bienvenu, à condition de battre cette baseline sur les mêmes données.
Même logique pour la catégorisation de nos transactions bancaires : un dictionnaire de règles et de fournisseurs connus fait 95 % du travail, et une catégorie posée à la main n'est jamais écrasée par l'automatique. Personne n'a envie d'une compta qui hallucine.
Règle 2 : l'IA là où il n'existe pas de règle écrite
Ce qu'aucun dictionnaire ne sait faire : écouter quarante minutes d'appel et en tirer ce qui a fonctionné, reformuler une objection, écrire un brief de coaching, générer une accroche d'appel à partir du contexte d'un prospect. Là, l'IA est irremplaçable, et on l'utilise sans complexe : analyse d'appels, coaching, préparation de contenu, suggestions en temps réel pendant les appels.
Le critère est simple : l'IA travaille sur du langage et du jugement, le code déterministe travaille sur des faits et des règles. Quand une tâche mélange les deux, on la découpe.
Règle 3 : l'IA n'est jamais seule sur un chemin critique
Une génération IA peut échouer : quota, panne, sortie inexploitable. Donc chez nous, l'IA est systématiquement en mode « best effort » : son échec dégrade l'expérience, il ne bloque jamais l'action.
Concrètement : quand on publie un article sur notre site, une traduction anglaise est générée automatiquement. Si elle échoue, l'article part quand même en français, et on retente plus tard. Quand un commercial charge sa liste d'appels, les accroches IA se génèrent en arrière-plan ; s'il appelle avant qu'elles n'arrivent, il appelle sans accroche. L'inverse, un pipeline où l'humain attend l'IA pour travailler, est exactement ce qu'on refuse de construire.
Règle 4 : une consigne de prompt est un souhait, pas une garantie
C'est peut-être la leçon la plus contre-intuitive. On avait interdit à nos prompts d'utiliser certains tics d'écriture typiques des modèles. Résultat : la consigne était suivie... la plupart du temps. « La plupart du temps », en production, ça veut dire non.
Depuis, chaque exigence importante existe en deux exemplaires : la consigne dans le prompt, et un garde-fou mécanique derrière. Le texte généré passe dans un nettoyage déterministe qui applique la règle quoi qu'il arrive. Les sorties des modèles sont parsées par des formats stricts : ce qui ne parse pas ne rentre pas en base, point. On ne discute pas avec une sortie malformée, on la rejette.
Dit autrement : on fait confiance à l'IA pour produire, jamais pour se contrôler elle-même. Le contrôle, c'est du code.
Règle 5 : l'hallucination se traite par l'architecture, pas par le prompt
Notre assistant temps réel donne des suggestions aux commerciaux pendant leurs appels. Le risque évident : qu'il invente une réponse à une question factuelle qu'il ne connaît pas. Écrire « ne réponds que si tu es sûr » dans le prompt ne suffit pas ; c'est une consigne, voir règle 4.
On a donc empilé trois couches. D'abord la consigne, oui. Ensuite un volant d'apprentissage : les questions restées sans réponse sûre sont extraites après l'appel et proposées à un humain, dont la réponse validée rejoint la base de connaissances des appels suivants. Enfin, pour les réponses documentées, une recherche dans nos propres playbooks : la suggestion est contrainte aux extraits trouvés, et la carte « réponse sourcée » n'existe tout simplement pas si la source n'existe pas. Zéro hallucination, non pas parce que le modèle est sage, mais parce que l'architecture rend l'invention impossible à cet endroit.
Ce que ça donne au quotidien
1. Par défaut, on écrit une règle. L'IA doit mériter sa place.
2. L'IA prend le langage et le jugement, le code prend les faits et les chiffres.
3. Un échec IA ne bloque jamais une action métier.
4. Toute exigence critique existe deux fois : dans le prompt, et dans un garde-fou mécanique.
5. Contre l'hallucination, on ne compte pas sur la docilité du modèle : on construit des chemins où inventer est impossible.
La formule qu'on se répète en interne : l'IA propose, le déterministe dispose. C'est moins spectaculaire qu'un « tout IA », et c'est exactement pour ça que ça tourne en production tous les jours.
