Votre catalogue a des trous. Des produits sans type, des descriptions vides ou copiées d'un fournisseur, des familles qui n'existent que dans la tête du responsable d'atelier. Vous le savez depuis des années, et personne n'a jamais eu les trois semaines pour s'y mettre.
Alors quand Odoo 20 annonce qu'un assistant peut, depuis la boutique, changer le nom, le prix ou la description d'un produit, vous écoutez. Et quand un prestataire propose de « passer tout le catalogue à l'IA en un week-end », vous êtes tenté. Nous aussi, nous l'avons été. Voici pourquoi nous avons fait beaucoup plus lentement, et ce que ça a donné sur un pilote en cours.
Le piège : une fiche réécrite que personne n'a relue
Un modèle de langage qui enrichit une fiche produit fait deux choses à la fois : il complète ce qui manque, et il invente ce qu'il ne sait pas. Un « filtre à air » devient « filtre à air haute performance », puis « filtre à air pour moteur quatre temps » sans que rien dans la fiche d'origine ne le dise. Sur une référence technique, c'est un retour client. Sur mille, c'est un catalogue dont plus personne ne sait ce qui est vrai.
Sur la mission qui a précédé ce produit, nous avions déjà enrichi plus d'un millier de fiches avec un modèle. Le garde-fou qui a tout changé tenait en une règle : si le nom généré perd un mot technique du nom d'origine, il est rejeté et l'original conservé. Le modèle peut compléter, il ne peut pas effacer.
Rien ne s'écrit dans l'ERP tant qu'un humain n'a pas validé. Pas « en général ». Jamais.
Les six verrous, dans l'ordre où un mot traverse
Le cas que nous avons construit est modeste : le modèle propose un type pour chaque produit (« filtre à air », « courroie », « bougie »). C'est le champ le plus utile pour le filtrage en boutique, et le moins risqué. Voici ce qui se passe entre la proposition et la fiche.
- 1. Le code refuse une proposition dont les mots ne figurent pas dans la fiche d'origine. Le modèle ne peut pas inventer un type. S'il propose « courroie » pour une fiche qui ne contient pas ce mot, la proposition est écartée avant d'être vue.
- 2. Les propositions arrivent dans Odoo dans des champs de transit, visibles dans une liste éditable. Le responsable accepte ou refuse, un par un ou en lot. La fiche elle-même n'a pas bougé.
- 3. Une seule fonction peut écrire dans Odoo, sur une liste fermée de champs, jamais le prix, le coût, la catégorie ni le stock. Un test lit tout le code pour s'assurer qu'aucune autre écriture n'existe.
- 4. Chaque écriture garde la valeur d'avant, qui a validé, quand, avec quel modèle. Une note est posée sur la fiche, y compris pour un refus et son motif. Dans deux ans, vous saurez pourquoi ce produit s'appelle comme ça.
- 5. Un lot entier s'annule d'une commande. Et un champ qu'un humain a modifié entre-temps n'est pas écrasé par l'annulation.
- 6. L'écriture est fermée par défaut, et ouverte seulement la nuit, sur créneau. Le reste du temps, la fonction d'écriture n'a pas le droit de tourner.
Ce que ça donne, en chiffres honnêtes
Premier lot sur le pilote : 22 produits d'une même famille, en attente de validation humaine au 14 octobre 2026. Après une itération sur la qualité des propositions, environ 20 types justes sur 22 à la relecture. Les deux restants sont des cas que le responsable tranchera lui-même, et c'est le but : le modèle propose, le métier décide.
Vingt-deux, pas mille. Volontairement. Le taux de refus du premier lot dit ce que valent les propositions ; lancer mille fiches avant de le connaître, c'est signer un chèque en blanc. Le rythme montera une fois le taux connu, pas avant.
Reste la question du prix, que l'édition par IA d'Odoo 20 pose à chaque fiche : ses fonctions d'IA se paient en crédits, 1 € pièce, sans que la consommation par demande soit publiée. Nos propositions sont calculées la nuit par un modèle ouvert, sur une machine équipée d'une bonne carte graphique : relancer un lot après une itération sur la qualité coûte zéro. C'est ce qui permet de commencer petit, de mesurer, et de recommencer autant qu'il faut. Le calcul complet : crédits, abonnements ou une machine à vous.
Quand il ne faut pas enrichir par IA
Si vos fiches d'origine sont vides, le verrou n°1 refusera tout, et il aura raison : un modèle ne peut pas déduire un type d'une référence de six chiffres. Dans ce cas, le travail commence par les données, à la main ou par import fournisseur, et l'IA vient après. Sur la mission qui a précédé, le principe du client était clair : données manquantes, on fait remplir l'équipe, on ne reconstruit pas.
Et si le champ à enrichir est le prix, la réponse est non, par construction. Pourquoi, et comment on s'en assure : l'agent qui ne peut pas toucher aux prix.
Cet enrichissement est l'une des capacités de notre serveur MCP pour Odoo. Si votre catalogue attend depuis des années, soixante minutes pour regarder l'état de vos fiches et décider par quelle famille commencer, sans engagement : prenez rendez-vous.