3. Passer en production sans immobiliser une ligne

La vraie question n'est pas de savoir si le modèle est performant. La vraie question est de savoir combien de temps il le restera sans ses auteurs. C'est cette contrainte qui doit dicter la méthode, et elle interdit le mode Big Bang : on ne bascule pas un atelier sur une décision automatisée pour prouver un concept.

Axe 1 : partir du geste, pas du modèle. Avant toute donnée, nommer la décision que le modèle doit changer, et l'indicateur opérationnel qui la mesure — temps d'immobilisation, taux de rebut, durée de diagnostic. Un critère d'acceptation exprimé en points de performance de modèle ne se traduit jamais tout seul en gain d'atelier. Un critère exprimé en minutes d'arrêt évitées, si.

Axe 2 : industrialiser la captation avant l'algorithme. C'est l'inverse de l'ordre naturel des projets, et c'est ce qui fait la différence à dix-huit mois. Matériel standard et remplaçable, procédure de pose écrite, conditions de mesure documentées, base de référence conçue pour grossir. Un modèle médiocre sur une captation maîtrisée se rattrape ; l'inverse est un chantier à reprendre de zéro.

Axe 3 : traiter le modèle comme un équipement. Une référence, des versions, une procédure de requalification après modification du procédé, un journal de ce qu'il a produit. C'est du craftsmanship logiciel appliqué à un objet statistique : il n'entre pas en production parce qu'il fonctionne, il entre en production parce qu'il est maintenable.

Ces trois axes ont une implication commune, souvent découverte trop tard : la sortie du modèle doit atterrir dans un flux qui existe déjà. Un score qui s'affiche dans un nouvel écran crée une charge de consultation supplémentaire, et il perd contre la production. Le même score qui pré-remplit un ticket de maintenance, une fiche de non-conformité ou un ordre d'intervention entre dans le fil numérique de l'atelier sans rien demander à personne. C'est le point où un projet d'IA cesse d'être une démonstration : quand plus personne ne va le voir, parce qu'il arrive de lui-même.

C'est la logique du Shazam industriel, qu'akawan a construit dans un contexte aéronautique où le diagnostic manuel coûte des immobilisations. La chaîne technique repose sur une captation sonore par microphones standards, une extraction des caractéristiques clés du signal par un modèle du framework Akoustik, et une comparaison en temps réel avec une base de données vectorielle évolutive : la base s'enrichit au fil des cas, ce qui fait de l'usage la source de l'amélioration plutôt qu'une charge de maintenance. Sur ce périmètre, la fiche Shazam industriel indique que 95 % des anomalies identifiées en vol sont résolues à l'arrivée.

4. Trois conditions pour que le modèle survive au départ de son auteur

Un propriétaire métier nommé. Pas un référent technique : un responsable de production ou de qualité qui répond de l'indicateur que le modèle est censé améliorer. C'est la forme de gouvernance transverse qui tient le mieux dans le temps, parce qu'elle est adossée à une responsabilité qui existait déjà.

Un critère d'arrêt écrit à l'avance. Décidez, avant la mise en service, ce qui vous ferait suspendre le modèle : un taux de faux signaux, un changement de procédé, un délai sans requalification. Sans ce critère, un modèle qui dérive reste en service, parce que l'arrêter ressemble à un aveu d'échec.

Ces deux premières conditions ne coûtent ni budget ni compétence rare. Elles coûtent une décision, prise avant la mise en service plutôt qu'après le premier incident. C'est aussi ce qui rend le sujet accessible à une ETI : il n'y a pas de taille critique pour nommer un propriétaire et écrire un critère d'arrêt.

Une revue calée sur le rythme industriel. La dérive ne se surveille pas en continu par un tableau de bord que personne n'ouvre. Elle se traite dans un rituel existant — revue qualité, réunion de maintenance — au même titre que l'étalonnage d'un moyen de mesure. Cette rationalisation itérative par la valeur est ce qui distingue un modèle qui vieillit bien d'un modèle qui vieillit seul. Nos partis pris sur ce point sont détaillés dans notre expertise Intelligence artificielle et dans notre approche de Diagnostic IA.

Un modèle n'est pas un livrable, c'est un équipement

Si vos pilotes ne passent pas en production, l'explication la plus probable n'est ni le modèle, ni les données, ni la maturité de vos équipes. C'est qu'ils ont été conduits comme des projets d'étude, avec une date de fin, alors qu'ils produisent un objet qui demande un cycle de vie. Un démonstrateur se termine ; un équipement s'entretient.

L'état cible ne ressemble donc pas à un portefeuille de cas d'usage. Il ressemble à une liste courte de modèles en service, chacun avec un propriétaire, un indicateur, une procédure de requalification et un critère d'arrêt. C'est moins spectaculaire qu'une feuille de route à quinze cas d'usage, et c'est la configuration dans laquelle l'IA finit par apparaître dans le compte de résultat plutôt que dans le budget.