Une sortie contractuelle
L’agent ne rend pas du texte libre mais une structure imposée, champ par champ, avec des valeurs autorisées. Ce qui ne respecte pas le format est rejeté avant d’atteindre votre base.
Des agents IA en production,
pas en démonstration.
Faire produire un texte convaincant à un modèle prend cinq minutes. Le faire tourner sur des milliers de fiches sans inventer, sans doublon et sans dériver demande un schéma strict, des contrôles et un point de validation humain. C’est là qu’est le travail.
Agents IA
Un agent ne vaut jamais mieux que la donnée qu’il lit.
Ce qui fait la différence
Trois exigences entre une démonstration et une mise en production
Un agent qui fonctionne sur dix exemples et qui déraille sur mille est le scénario habituel. Voici ce qui l’évite.
Des contrôles avant écriture
Cohérence avec les données existantes, détection des doublons, valeurs hors bornes. Un modèle produit toujours une réponse plausible, y compris quand il n’a pas l’information : c’est le contrôle qui fait la différence, pas la confiance.
Un humain sur les cas douteux
Ce qui passe les contrôles s’écrit seul, ce qui hésite part en file de validation. L’enjeu n’est pas de retirer l’humain, c’est de ne lui présenter que les cas qui méritent son attention.
Notre méthode
Quatre étapes, et la donnée traitée avant le modèle.
La majorité du travail se passe avant le premier appel à un modèle. C’est aussi la partie que les démonstrations ne montrent jamais.
- (01)
Fiabiliser la donnée d’entrée
Nettoyage, dédoublonnage, normalisation des champs qui serviront de référence. Un agent nourri de données incohérentes produit des sorties incohérentes, plus vite et en plus grand nombre.
- (02)
Définir la sortie attendue
Un schéma strict, avec les champs obligatoires, les formats et les valeurs autorisées. C’est ce contrat qui rend le résultat vérifiable par une machine plutôt que par un relecteur.
- (03)
Mesurer sur un échantillon
Quelques centaines de cas traités et comparés à un jugement humain, avec un taux d’erreur relevé. Sans cette mesure, on ne sait pas si l’agent est utilisable, on l’espère.
- (04)
Mettre en production avec des garde-fous
Traitement par lots, journalisation, alerte au-delà d’un seuil d’erreur, file de validation humaine et suivi du coût par traitement.
En pratique
Cas d’usage
Les tâches où un agent gagne vraiment sont répétitives et vérifiables.
Un agent est intéressant quand la tâche revient des milliers de fois et qu’on peut contrôler automatiquement sa sortie. Enrichir un catalogue, normaliser des libellés, trier des demandes entrantes, préparer un premier jet de fiche produit. À l’inverse, une décision unique et lourde de conséquences n’a rien à gagner à être déléguée.
- Enrichissement et normalisation de catalogue
- Tri et orientation des demandes entrantes
- Premier jet de contenu, relu ensuite
- Extraction d’informations depuis des documents
Cas client
Motomax, un agent qui enrichit des milliers de références.
Un catalogue de pièces moto dont les compatibilités étaient gérées à la main. Après avoir fiabilisé la base et normalisé marque, modèle, année et cylindrée, un agent piloté par un flux automatisé enrichit les produits selon un schéma strict, avec un routage conditionnel qui écarte les doublons.
–80 %
sur le temps de traitement des produits
Automatique
des fiches enrichies et validées sans intervention manuelle
Un socle stable
pour les prochaines itérations IA de Motomax
Nos engagements
Ce que nous tenons, et ce que nous ne promettons pas.
Un modèle de langage produit des erreurs, y compris bien encadré. Nous nous engageons sur les contrôles et sur la mesure, pas sur une exactitude absolue.
Taux mesuré
Erreur relevée sur échantillon avant toute mise en production.
Sortie contrainte
Schéma strict, ce qui ne s’y conforme pas est rejeté.
Coût suivi
Prix par traitement mesuré, pas découvert sur la facture.
Aucune exactitude promise
Un point de validation humaine reste prévu par conception.
Questions fréquentes
Les questions qui comptent.
Un agent peut-il inventer des informations ?
Oui, c’est le comportement normal d’un modèle de langage : il produit ce qui est plausible, pas ce qui est vrai. C’est pour cela que la sortie est contrainte par un schéma et vérifiée contre vos données existantes avant écriture. La question n’est pas d’empêcher l’erreur mais de l’attraper.
Nos données servent-elles à entraîner le modèle ?
Cela dépend du fournisseur et de l’offre souscrite. Nous vérifions ce point avant de choisir, et privilégions les offres qui excluent la réutilisation. Si vos données sont sensibles, dites-le au cadrage, cela change le choix technique.
Combien cela coûte-t-il à l’usage ?
Le coût se calcule par traitement et se mesure sur l’échantillon, avant la mise en production. C’est un critère de décision à part entière : une automatisation qui coûte plus que le temps qu’elle remplace ne se justifie pas, et nous le dirons.
Faut-il un modèle spécialisé ou entraîné sur nos données ?
Rarement. Sur la plupart des tâches, un modèle généraliste bien encadré, avec un bon schéma de sortie et vos données en contexte, fait le travail. Un entraînement spécifique coûte beaucoup et ne se justifie que sur des cas très particuliers.
Cela remplace-t-il des personnes ?
Sur les tâches que nous traitons, cela remplace des gestes, pas des postes : recopier, normaliser, trier. Le temps récupéré va généralement à ce que personne n’avait le temps de faire. Nous ne vendons pas de réduction d’effectif, ce n’est pas ce que nous savons mesurer.
Commençons par une tâche répétitive et vérifiable.
Un échange pour identifier la tâche, mesurer son volume et vérifier qu’elle se contrôle automatiquement, puis une proposition.
Parler de mon projet