Aller au contenu
IA 8 min

L'IA en production pour de vrai : ce qu'on a appris sur nos propres produits

On répète qu'une agence IA doit montrer un système vivant en production. Voici les nôtres, Refaudit et UptimeEZ, et les leçons qu'on en a tirées, y compris les ratées.

Par Laurent Tulpan

Dans notre article sur comment choisir une agence IA, la toute première question qu’on conseille de poser est brutale : « montrez-moi un système d’IA en production depuis six mois, et dites-moi qui le maintient. » Il serait malhonnête de la poser sans y répondre nous-mêmes. Alors voici nos deux produits, ce qu’ils font, et surtout ce qu’ils nous ont appris, y compris là où on s’est trompés.

Refaudit : quand l’IA doit corriger, pas seulement pointer

Refaudit est notre SaaS qui audite la conformité, la sécurité et l’accessibilité d’un site, puis propose les corrections, par IA. Audit triple : réglementaire (mentions, RGPD, cookies), sécurité (vulnérabilités courantes, headers, dépendances), accessibilité (RGAA, WCAG, contraste, structure). Pour chaque problème, il ne se contente pas de dire « c’est cassé », il écrit la correction, et dans les cas simples il l’applique.

C’est cette exigence qui nous a fait passer deux ans à le construire plutôt qu’à le pitcher. Les outils d’audit qui pointent les problèmes existent par dizaines. Le pas difficile, celui que l’IA rend possible mais pas facile, c’est que la correction proposée soit réellement utile, pas seulement plausible. Une IA générative produit sans effort une suggestion qui a l’air juste. La rendre juste pour de vrai, sur un vrai site, sans casser autre chose, c’est un tout autre travail.

La leçon. L’écart entre « plausible » et « juste » est l’endroit où meurent la plupart des projets IA. Une démo vit dans le plausible. La production exige le juste. Tout le temps qu’on croit gagner en branchant un modèle, on le repaie en fiabilisation.

UptimeEZ : le problème n’était pas de détecter, c’était de ne pas crier pour rien

UptimeEZ surveille des sites et détecte les pannes qu’un simple test de disponibilité ne voit pas. Parce qu’un site peut répondre un code 200 tout en étant cassé pour l’utilisateur : panier qui ne valide plus, formulaire muet, page à moitié chargée. Détecter ça demande de comprendre ce que « fonctionne » veut dire, pas seulement si le serveur répond.

Mais la vraie difficulté n’a pas été la détection. Elle a été le bruit. Un matin, le système a levé quarante-sept alertes. Quarante-trois étaient fausses. Un outil qui crie au loup quatre fois sur cinq, on l’éteint en une semaine, et il ne sert plus à rien. On a raconté cet épisode en détail dans quarante-sept alertes, quarante-trois fausses, et la liste des pannes invisibles dans sept pannes que la supervision classique ne voit pas.

La leçon. Sur un système d’alerte, le taux de faux positifs n’est pas un détail technique, c’est le critère de survie du produit. La valeur d’une alerte ne se mesure pas à leur nombre, mais à leur justesse. On a passé bien plus de temps à faire taire les fausses alertes qu’à détecter les vraies.

Ce que ces deux produits nous ont appris pour vos missions

Les deux histoires disent la même chose sous deux angles. Le moment difficile de l’IA n’est jamais la démo, c’est la vie en production, sur des données réelles, dans la durée. C’est exactement pour ça que huit projets IA sur dix en PME ne passent jamais ce cap, comme on l’explique dans pourquoi les projets IA échouent.

Trois principes en sortent, qu’on applique sur chaque mission Pôle IA :

Viser le juste, pas le plausible. Une sortie d’IA qui a l’air correcte n’est pas une sortie correcte. On mesure l’écart, et on ne met en production que ce qui tient sur des cas réels.

Traiter le faux positif comme un ennemi prioritaire. Un système qu’on finit par ignorer ne vaut rien. La qualité du signal passe avant la quantité de fonctionnalités.

Garder l’humain sur les décisions à enjeu. Tant que le signal n’est pas assez propre, une validation humaine reste sur les sorties sensibles. Ce n’est pas un aveu de faiblesse de l’IA, c’est la condition pour l’utiliser sans se brûler. C’est aussi ce que demande l’AI Act pour les usages sérieux.

On ne conseille bien que ce qu’on a soi-même mis en production et gardé vivant. Nos produits ne sont pas des vitrines, ce sont nos terrains d’apprentissage, payés en heures et en fausses alertes. C’est ce qu’on ramène chez vous.

Pour aller plus loin

Questions fréquentes

On répond sans détour.

  • Quelle est la vraie difficulté de l'IA en production ?

    Ce n'est pas de produire une réponse, c'est de produire une réponse fiable et utile, à chaque fois, sur des données réelles. La démo marche toujours. La production révèle les cas de bord, les faux positifs et les sorties plausibles mais fausses. L'essentiel de l'effort passe à réduire ces écarts, pas à brancher le modèle.

  • Comment gérer les faux positifs d'un système d'IA ?

    En mesurant leur taux, en le traitant comme le premier critère de qualité, et en gardant un humain sur les décisions à enjeu tant que le signal n'est pas assez propre. Un système qui crie au loup trop souvent finit ignoré, ce qui est pire que pas de système du tout. La valeur d'une alerte se mesure à sa justesse, pas à leur nombre.

  • Pourquoi une agence devrait-elle avoir ses propres produits IA ?

    Parce que construire et opérer un produit IA dans la durée apprend ce qu'aucune démo n'enseigne : la maintenance, la dérive, les coûts réels, la conformité, la relation avec l'utilisateur quand le modèle se trompe. On ne conseille bien que ce qu'on a soi-même mis en production et gardé vivant.

On en parle

Vous identifiez une tâche automatisable ? On la cadre ensemble.

Vingt minutes pour vérifier si votre cas colle au format Pôle IA externalisé. Si oui, on cale un atelier de cartographie.