Avant de commencer : versions et écrans concernés
Manufacturing AI Work-Instruction Copilot est publié sur Odoo Apps pour Odoo 17.0, 18.0 et 19.0. Sur les trois fiches, il coûte 49 € HT, en paiement unique par version.
La mise en route passe par quatre écrans : l'assistant AI Provider Setup, les paramètres du module, la liste des Prompt Templates et la liste AI Work Instructions › AI Providers. Ensuite, pendant la première semaine, entrent en jeu AI Work Instructions › Reporting › AI Cost (Estimated) et les champs d'état des enregistrements. Si vous voulez d'abord une vue d'ensemble des menus et des enregistrements, consultez le fonctionnement interne du module.
Le cas : Mecanizados Albera met en route le copilote
Exemple Cas illustratif : l'entreprise et ses chiffres sont inventés pour expliquer le flux.
Mecanizados Albera est une entreprise fictive qui fabrique des pièces usinées et travaille avec Odoo 18. Marta, sa responsable de production, a installé le module et veut le rendre opérationnel pour que son équipe relise les premières instructions de travail. Voici l'ordre qu'elle suit.
Première étape : créer le fournisseur d'IA
Marta ouvre la boîte de dialogue AI Provider Setup. Elle saisit un nom dans Name, choisit Ollama (self-hosted) dans Provider Type, remplit Model Name (vide au départ, avec un texte d'exemple) et vérifie Api Url, qui pointe vers localhost. Elle clique sur Create Provider.

Le fournisseur apparaît dans AI Work Instructions › AI Providers. Dans la base de Marta, il y a deux lignes, l'une pour OpenAI et l'autre nommée Ollama Local, toutes deux de type Ollama (self-hosted).

AI Work Instructions › AI Providers avec deux fournisseurs et tous les coûts encore à zéroLe module définit un état de connexion, connection_status, avec trois valeurs : Unknown, OK et Error. Marta ne considère pas cette étape comme terminée tant qu'elle ne voit pas OK.
Deuxième étape : les paramètres du module
Sur l'écran des paramètres, le module regroupe ses options dans Generation & Caching et Data & Privacy. Voici les champs, avec leur libellé et leur nom technique :
AI Cache TTL (days)(mai_cache_ttl_days), un nombre entier de jours.Pre-Generation Batch Size(mai_pregen_batch), un nombre entier.Output Content Filter(mai_content_filter_enabled), une case à cocher.Q&A Retention (days)(mai_retention_days), un nombre entier de jours.Training Cleanup (days)(mai_training_retention_days), un nombre entier de jours.Max Attachment Size (MB)(mai_max_attachment_mb), un nombre entier.Structured JSON Logs(mai_json_logs), une case à cocher.
Marta n'improvise pas les valeurs : elle fixe les jours de conservation avec la personne chargée de la protection des données dans l'entreprise, et la taille maximale des pièces jointes avec celle qui prépare les plans et documents. Elle coche Output Content Filter et active Structured JSON Logs à la demande de son équipe informatique.
Troisième étape : passer en revue les modèles de prompt
Dans la liste des Prompt Templates, elle trouve six modèles par secteur : Assembly, Chemical, Food & Beverage, General, Machining et Packaging. La liste affiche les colonnes libellé, par défaut, version et actif. Comme Albera fait de l'usinage, Marta regarde Machining et vérifie dans ces colonnes lequel est marqué par défaut et lesquels sont actifs.
Les états que Marta verra sur chaque enregistrement
Le module utilise plusieurs champs d'état. Nous les listons avec leurs valeurs telles que le module les définit ; cette page ne suppose aucune transition que le code ne décrit pas.
- Prégénération (
ai_pre_generation_state) :Not Started,Queued,GeneratedetError. - État de l'instruction (
ai_instruction_status) :Not Generated,Draft,Pending Approval,ApprovedetLocked. - Approbation (
state) :Pending ApprovaletApproved. - Un autre champ
state, avec plus de valeurs :Draft,Pending Approval,Approved,LockedetReplaced.
Pour Marta, l'essentiel est de distinguer les champs : Replaced n'existe que dans le dernier, et Queued et Generated appartiennent au champ de prégénération, pas à celui de l'instruction. Si quelqu'un de son équipe dit « elle est approuvée », elle lui demande dans quel champ il l'a vu.
Ce que Marta vérifie la première semaine
Une fois le module en service, Marta prend un moment chaque matin pour ces contrôles :
- L'état de connexion : s'il affiche
Errorou reste surUnknown, elle le note avant de continuer à générer. - Les enregistrements dont
ai_pre_generation_stateest surErrorou encore surQueued. - Les instructions en
Pending Approval, pour qu'une personne compétente techniquement les relise. - La liste
AI Work Instructions › Reporting › AI Cost (Estimated), où elle ne voit pour l'instant que ses deux fournisseurs avec des coûts à zéro. - Les valeurs de
Pre-Generation Batch SizeetMax Attachment Size (MB), au cas où elle voudrait les ajuster selon ce qu'elle a appris.

AI Cost (Estimated) la première semaine : les deux fournisseurs et des coûts à zéro, encore sans enregistrements de consommationElle ouvre aussi la boîte de dialogue Manufacturing AI GDPR pour savoir ce qu'elle demande avant d'en avoir besoin. Elle voit le champ Mode sur Data Subject Access (export), les champs Data Subject et Limit to Work Order, et les boutons Run et Close. Elle n'exécute rien : elle se familiarise simplement avec l'outil.

Manufacturing AI GDPR avec Data Subject et Limit to Work Order non remplis, encore sans enregistrementsQuand quelque chose cloche et qu'un avertissement apparaît, Marta se réfère aux messages d'erreur du module expliqués un par un.
Les leçons du cas
La mise en route est plus ordonnée si vous séparez trois choses : le fournisseur d'IA, les paramètres et les modèles. Chacun a son propre écran et peut être vérifié séparément.
Les valeurs des paramètres ne sont pas de simples choix techniques : les jours de Q&A Retention (days) et Training Cleanup (days) gagnent à être fixés avec la personne responsable des données dans votre entreprise.
Enfin, les états : le module a plusieurs champs d'état, avec des valeurs qui se répètent (Pending Approval, Approved). Savoir quel champ vous regardez évite les malentendus dans l'équipe.
Comment FlexigoTech vous accompagne
Chez FlexigoTech, nous déployons Odoo 17, 18, 19 et 20 et développons des connecteurs et intégrations sur mesure. Si vous souhaitez être accompagné dans la mise en route du copilote ou l'adapter à votre atelier, vous trouverez les détails sur la page du module sur flexigotech.com et sur sa fiche Odoo Apps.
À lire aussi
Vérifié dans le code du module (version 19.0) et dans les sources citées
Sources
- Code du module : flexigo_manufacturing_ai_work_instruction_copilot 19.0 (40c663bd): models/res_config_settings.py
- Code du module : flexigo_manufacturing_ai_work_instruction_copilot 19.0 (40c663bd): models/mrp_ai_provider.py
- Code du module : flexigo_manufacturing_ai_work_instruction_copilot 19.0 (40c663bd): models/mrp_production.py
- Code du module : flexigo_manufacturing_ai_work_instruction_copilot 19.0 (40c663bd): models/mrp_workorder.py
- Code du module : flexigo_manufacturing_ai_work_instruction_copilot 19.0 (40c663bd): models/mrp_workorder_dependency.py
- Code du module : flexigo_manufacturing_ai_work_instruction_copilot 19.0 (40c663bd): models/mrp_workorder_instruction.py
- apps.odoo.com/apps/modules/19.0/flexigo_manufacturing_ai_work_instruction_copilot
- apps.odoo.com/apps/modules/17.0/flexigo_manufacturing_ai_work_instruction_copilot
- apps.odoo.com/apps/modules/18.0/flexigo_manufacturing_ai_work_instruction_copilot
- flexigotech.com/en/services.html
