Quatre pannes qui ne lèvent aucune erreur.
Les projets d'intelligence artificielle échouent rarement sur la capacité du modèle. Ils échouent sur des défauts qui ne produisent aucun message, rendent un résultat plausible, et passent tous les contrôles qu'on fait spontanément.
Ce qui bloque un projet n'est presque jamais le modèle
Les travaux publiés sur l'échec des projets d'intelligence artificielle convergent sur un point : les initiatives qui n'atteignent jamais la production se comptent en larges majorités, et les causes citées ne sont pas la capacité des modèles. Ce sont l'évaluation absente, l'intégration au système existant, et la fiabilité en conditions réelles.
Cette formulation reste abstraite tant qu'on n'a pas vu à quoi ressemble une de ces pannes. Voici quatre cas que nous avons vécus. Ils n'ont rien de commun sur le plan technique, et ils partagent pourtant le même trait : aucun ne produit d'erreur. Chacun passe un contrôle superficiel, et chacun aurait été découvert par un utilisateur plutôt que par nous.
Un drapeau d'aperçu, et l'intégration ne produit rien
Une intégration à un service tiers était branchée, appelée en production, et répondait correctement à chaque sollicitation. Elle ne produisait pourtant rien d'utilisable : un paramètre valant « aperçu » par défaut faisait sortir chaque document barré de la mention correspondante.
Le contrôle habituel ne pouvait pas voir le problème. L'appel partait, le service répondait, le document arrivait. Tout ce qu'on vérifie normalement était vert.
Le plus instructif est ailleurs. Basculer ce paramètre n'était pas un détail technique : cela changeait qui paie quoi, et donc le traitement comptable et fiscal de l'opération. Trois fichiers sans rapport apparent devaient bouger le même jour.
Un durcissement d'accès, et la table ne rend plus rien
Nous avons activé le cloisonnement par ligne sur une table de base de données, en documentant qu'aucun accès applicatif n'était souhaité. Ce que le moteur en comprend est différent de ce que la phrase suggère : activer le cloisonnement sans définir de politique ne signifie pas « réservé au service », cela signifie personne.
Résultat : une ligne parfaitement présente en base était comptée zéro par l'application, et le parcours utilisateur répondait qu'un identifiant valide n'était plus valable. Aucune erreur, aucun refus, aucune trace. Le symptôme est strictement identique à celui d'un identifiant inconnu.
La cause profonde n'est pas la base de données, c'est la méthode de vérification. Un durcissement d'accès se contrôle spontanément dans le sens « ça n'écrit plus », alors que c'est la lecture qui casse, et qu'elle casse en silence. Zéro ligne est une réponse valide, indiscernable d'une absence légitime.
Une variable modifiée, un processus qui ne l'a pas lue
Un réglage est corrigé dans le fichier de configuration. La valeur est juste, le fichier est déployé, et le comportement ne change pas. On modifie alors autre chose, on cherche ailleurs, et on finit par douter du réglage lui-même.
La plupart des programmes lisent leur configuration au démarrage et la gardent en mémoire. Tant que le processus n'a pas été relancé, il travaille avec l'ancienne valeur, quel que soit le contenu du fichier sur le disque.
Ce cas paraît trivial écrit noir sur blanc. Il coûte pourtant des heures parce qu'il se déguise en autre chose : le symptôme observé est « ma correction ne marche pas », ce qui oriente vers la correction et jamais vers le cycle de vie du processus. La vérification consiste à prouver que le processus qui répond est bien le nouveau, pas à relire la valeur dans le fichier.
Un déploiement parti de la copie de travail
Le quatrième cas est le plus banal et le plus difficile à rattraper. Un déploiement construit à partir du dossier de travail plutôt que du dépôt de code embarque tout ce qui traîne sur le poste : un fichier modifié et non validé, un essai oublié, une correction faite localement et jamais versionnée.
Cela fonctionne, souvent longtemps. Puis la production se met à contenir du code que personne ne retrouve dans l'historique, et la personne qui reprend le sujet cherche pendant des heures une modification qui n'a jamais existé ailleurs que sur une machine.
Le remède tient en une phrase : ce qu'on déploie vient du dépôt, et un déploiement commence par vérifier que l'arbre de travail est propre. Une règle ennuyeuse, dont la valeur ne se voit que le jour où quelqu'un d'autre reprend le système.
Ce que ces quatre cas ont en commun
Aucun ne lève d'erreur. Tous rendent un résultat plausible. Et tous passent le contrôle qu'on fait spontanément, parce que ce contrôle vérifie que le mécanisme tourne au lieu de vérifier qu'il produit le bon effet.
C'est la même leçon sous quatre formes. Un contrôle qui ne peut pas échouer ne contrôle rien. Voir passer une requête ne prouve pas qu'elle a produit un effet. Voir un conteneur en marche ne prouve pas qu'il sert la bonne version. Voir zéro ligne ne prouve pas qu'il n'y a rien à voir.
Ces vérifications coûtent quelques minutes chacune. Elles sont exactement ce qui sépare un prototype qui impressionne d'un système qui tient, et elles n'apparaissent dans aucune démonstration.