Déployé et vérifié en test
Le mode de livraison gouverne les services
Odoo doit vérifier la compatibilité des articles, des préparations, du conditionnement, de l’adresse et du délai avec Express ou Planifiée. L’interface doit refléter les mêmes règles du marché à la confirmation, y compris depuis les recettes et le planning. Express exclut préparation, découpe et sous vide ; Planifiée commence au minimum 24 heures complètes après la commande. L’approvisionnement « sur commande » reste interne, sans déduire la disponibilité du seul stock physique. Ces contrôles sont déployés et vérifiés dans l’environnement de test. Lire ADR-040.
Principes
Des frontières simples à auditer
Odoo est le protocole
Chaque demande, proposition, validation, achat, mission et exception possède un identifiant, une version, un état et une provenance durables.
Knowledge gouverne le corpus
Les pages, versions et approbations sont administrées dans Odoo. L’index vectoriel nécessaire au RAG reste un composant distinct à construire.
La mémoire ne fait pas foi
Honcho peut conserver le contexte conversationnel ; seul Odoo porte profils consentis, commandes, validations, transactions et audit.
Vue d’ensemble
Architecture cible conceptuelle
WhatsApp, réseaux & site
Conversation, demande et suivi client
Orchestrateur commercial
Qualifier, conseiller, proposer et obtenir l’accord
Corpus & futur RAG
Pages approuvées dans Knowledge, puis index dérivé et contrôlé
Interfaces métier contrôlées
Recherche, autorisations, validation et journal
Orchestrateur commercial
Produit une intention structurée
Odoo
Protocole, source de vérité et file de travail durable
Odoo
Publie une mission versionnée
Orchestrateur opérationnel
Planifier, solliciter, suivre et remonter les exceptions
Partenaires & terrain
Validation d’achat, préparation, collecte et contrôle
Livraison
Remise, encaissement et preuve d’exécution
Le socle ERP, les modules Profils partenaires et Catalogue métier, la suite Recettes V1 avec quantités AP/EP, le cycle commercial des ingrédients, le corpus OCA Knowledge et deux runtimes OpenClaw séparés sont déployés. Le compte web de test est désormais relié à Odoo pour le contact, l'adresse, le foyer, les membres, les préférences, les consentements et les paniers ; la couche du site conserve l’identité de connexion, la session, le suivi technique de synchronisation et les publications dérivées des recettes et offres produits. La suite recettes contient 291 identités et 165 versions : 161 versions courantes sont approuvées pour la phase R&D et publiées dans Knowledge en français, anglais et arabe ; 4 anciennes révisions sont archivées. Un registre vide et humainement revu est prêt à conserver les futurs signaux de demande sans automatiser l'achat. Le runtime commercial dispose désormais d’un connecteur de contexte client Odoo et de mémoire consentie Honcho, testé avec des messages fictifs. Les messages privés WhatsApp sont ouverts à tous les expéditeurs sur demande du propriétaire ; les groupes, commandes de contrôle et outils d’écriture métier restent désactivés. Le runtime opérationnel demeure privé, sans canal ni outil. Le contexte client est raccordé en test ; la fiabilisation du profil conversationnel réel, l’enregistrement des programmes personnalisés, le RAG vectoriel et les flux opérationnels restent à construire : le compte web actif en test n'est ni un service commercial ouvert ni une capacité agentique.
Cœur opérationnel
Odoo porte le protocole et les faits opposables
Les orchestrateurs lisent et proposent des changements par des interfaces métier limitées. Seuls les objets validés dans Odoo déterminent ce qui a été promis, accepté, acheté ou exécuté.
Référentiels
- Produits et catégories
- Fournisseurs et points de retrait
- Recettes et ingrédients
- Zones et horaires
Demandes et faits volatils
- Demandes de recettes et ingrédients
- Offres horodatées
- Disponibilités et expiration
- Prix et délais partenaires
Relation client
- Contacts et adresses
- Points de livraison validés
- Profils de foyer
- Préférences et consentements
Engagement commercial
- Propositions versionnées
- Confirmations client
- Commandes et substitutions
- Factures et remboursements
Exécution
- Demandes d’achat et validations
- Missions de collecte ou livraison directe
- Contrôles de consolidation
- Remise et paiement à la livraison
Traçabilité
- Source et fraîcheur de chaque donnée
- Validations et reprises humaines
- Clés d’idempotence et versions
- Incidents et réclamations
Un message peut expliquer une situation, mais la commande ne progresse que lorsqu’une transition autorisée est enregistrée dans Odoo avec son auteur, son heure et sa version. De même, un signal de demande mesure un intérêt : il ne prouve jamais une disponibilité fournisseur.
Le panier produits unique constitue la base d'une future commande ponctuelle, sans abonnement ni recette vendue. La livraison exige un point d’adresse situé dans un polygone éligible publié ; le nom d’une ville ne suffit pas. Harhoura est publiée comme première zone réelle dans Odoo. Livry applique 15 MAD jusqu’à 3 km, puis 1,5 MAD par kilomètre supplémentaire entièrement parcouru, dans une limite de 20 km. La distance est calculée à vol d’oiseau depuis le point de collecte configurable dans Odoo. Le créneau quotidien va de 9 h à 23 h 30, heure du Maroc, avec une capacité de 20 commandes et un horizon de sept jours. Les commandes Express sont possibles de 9 h à 22 h 30 pour conserver le délai de 60 minutes. La consultation des créneaux ne réserve aucune capacité. Les trois autres villes restent non desservies. Aucun suivi GPS continu n’est prévu.
Actif sur le site de test
Odoo publie les offres, le site calcule l’estimation
Odoo reste le référentiel des prix et règles commerciales. Une publication persistante rassemble les produits, traductions, conditionnements, paliers tarifaires et disponibilités. Le site la lit pour afficher la boutique et calculer automatiquement le panier.
Une révision durable détecte les changements toutes les cinq secondes, avec reprise après interruption. La publication expire si sa fraîcheur n’est plus vérifiée ; un prix absent reste inconnu. La validation finale relit les conditions applicables au client dans Odoo et demande son accord sur le montant présenté.
Cette séparation évite un appel ERP à chaque modification visuelle du total. Le panier et la commande restent enregistrés dans Odoo ; aucun achat fournisseur ou paiement n’est automatisé. ADR-034.
Connaissance & temps réel
Le corpus est livré ; le RAG vectoriel reste à construire
| Couche | Exemples | Usage autorisé | Interdit |
|---|---|---|---|
| Corpus OCA Knowledge — installé | Pages, catégories, étiquettes, révisions et approbations | Rédiger, relire et gouverner les sources autorisées | Être présenté comme un moteur RAG vectoriel complet |
| Index RAG — à construire | Fragments approuvés, embeddings et références aux sources | Retrouver une connaissance pertinente et sourcée | Devenir une seconde source de vérité ou ignorer les droits |
| Référentiels Odoo | Produits actifs, profils, partenaires, zones, politiques approuvées | Filtrer et construire une proposition conforme | Contourner une règle métier ou un consentement |
| Données volatiles | Disponibilité, poids, prix, capacité, heure de préparation | Confirmer une ligne si la source est valide et non expirée | Réutiliser une valeur expirée comme promesse |
| Événements d’exécution | Acceptation humaine, collecte, contrôle, remise, encaissement | Faire progresser l’état de commande | Être remplacés par un résumé généré |
OCA Knowledge fournit aujourd’hui le corpus gouverné, pas le découpage, les embeddings, l’index vectoriel ou l’interface de récupération. Le futur index restera un dérivé régénérable. Chaque fragment devra conserver sa source, sa révision, sa visibilité et son responsable éditorial. Une information susceptible de changer pendant la commande doit être interrogée dans Odoo ou confirmée par le terrain.
Mémoire conversationnelle
Honcho conserve du contexte, jamais l’état de la commande
Deux espaces séparés
La mémoire auto-hébergée possède un espace pour le rôle commercial et un autre pour le rôle opérationnel.
Traitements Honcho
L’API et le traitement de mémoire sont démarrés depuis le 21 septembre 2026. Le stockage est privé ; les calculs IA font appel à un fournisseur externe.
Contexte client
Le connecteur relit le foyer Odoo et, après accord séparé, les trois dernières déclarations textuelles du client dans Honcho. La conservation retenue est de 30 jours glissants ; les profils confirmés restent dans Odoo.
Knowledge gouverne ce qui est publiable, le futur RAG retrouve les passages utiles, Honcho mémorise le contexte conversationnel et Odoo demeure le seul registre métier.
Prompt corrigé, parcours commercial à compléter
Reconnaître le client avant de poser des questions
La conduite du dialogue privilégie désormais une première proposition ajustable et une seule question décisive à la fois. Foyer, portions, goûts, temps, budget, repas scolaires ou au travail servent la demande sans questionnaire exhaustif. La conservation et le réchauffage sont des conseils contextualisés, pas des filtres systématiques ; une contrainte déclarée ne bloque que le repas concerné. Sans accès au catalogue, les idées proposées restent indicatives. La délégation native est suspendue sur le canal client pour empêcher la transmission de rapports internes ; le retour privé des sous-agents reste à valider avant réactivation.
L’assistant se présente comme DailyFresh. Son prompt couvre l’accueil, la qualification progressive des repas et le respect du refus, sans inventer une commande ni une notification. Ces comportements ont été testés. Le raccordement du dossier partagé permet désormais les corrections ciblées du foyer et leur reprise sur le site ; le prochain échange WhatsApp humain reste à observer après les essais du connecteur. L’agent consulte désormais les recettes publiées et les quatre modèles approuvés dans une bibliothèque locale synchronisée. Il peut proposer des variantes avec des ingrédients courants au Maroc, en distinguant inspiration culinaire, recette validée et disponibilité commerciale. Les réponses peuvent inclure les liens exacts des recettes consultées. Le panier est maintenant partagé avec le site : produits, ingrédients de recettes, quantités et chiffrage sont enregistrés dans un devis brouillon Odoo. L’écriture du programme personnel reste à connecter. Un raccourci WhatsApp est disponible sur toutes les pages du site pour ouvrir la conversation avec l’assistant IA DailyFresh ; la salutation proposée suit la langue choisie et son envoi reste à l’initiative du visiteur.
Pour les essais demandés le 21 septembre 2026, l’orchestrateur commercial utilise GPT-6 Astra en extra high, avec le niveau effectif vérifié. Le compte WhatsApp est associé, connecté et ouvert aux messages privés de tous les expéditeurs sur demande du propriétaire.
Dans le parcours cible, l’agent recherche le contact Odoo et relit son profil et son programme. Il propose une aide facultative pour compléter les seules informations utiles, sans répéter le questionnaire ni bloquer la demande commerciale. Le client pourra adapter un programme de base ou créer le sien selon les repas à la maison, au travail ou à l’école, les portions, le budget et le temps disponible.
Le connecteur installé reconnaît le contact à partir des métadonnées de canal et relit le foyer à chaque réponse. Le refus de personnalisation masque le profil sans bloquer une demande générale. La mémoire possède un accord distinct, saisissable dans le backoffice ou recueilli explicitement par l’assistant : les échanges expirés sont exclus des lectures, puis supprimés, et un retrait déclenche aussi leur effacement. Le connecteur a été testé avec des correspondants fictifs ; le propriétaire a ensuite demandé l’ouverture des messages privés à tous les expéditeurs.
La première mémoire conserve les textes entrants, sans réponses de l’agent, médias ou ancien historique importé. Les accords explicites et les corrections de foyer sont raccordés au dossier partagé. Les mises à jour du site contrôlent la révision Odoo pour préserver une modification plus récente ; les champs inconnus restent non renseignés. Le panier conversationnel est raccordé : un client non inscrit peut commencer sur WhatsApp et retrouver son panier après inscription avec le même numéro. Les changements récents et les rejeux sont contrôlés. L’outil ne confirme aucune commande et ne déclenche ni paiement ni réservation. Les programmes enregistrés et la finalisation par WhatsApp restent à raccorder. Les programmes personnels restent lus par leurs dates et leur statut ; les modèles approuvés sont maintenant consultables avec leurs repas et ingrédients.
État des modules
Référentiels, compte web et recettes déployés, exécution encore à construire
Les fondations de profil, de catalogue, de recettes structurées et de corpus sont installées dans Odoo. Le référentiel culinaire contient 291 identités de recette et 165 versions : 161 versions courantes sont approuvées pour la phase R&D et publiées dans Knowledge en français, anglais et arabe, tandis que les anciennes révisions sont archivées. Le compte client ajoute inscription, connexion, édition du profil et du foyer. Une session authentifiée retrouve un seul panier produits par quantités depuis un autre appareil, sans retransmettre le téléphone au moment de l'action. Depuis une recette, les produits disponibles choisis sont convertis dans leur unité de vente puis fusionnés atomiquement dans ce même panier ; la recette reste une inspiration et n'est jamais vendue comme un article. Les ingrédients et étapes peuvent être regroupés par composant, comme Chermoula et Friture sur la recette pilote. Le panier produits permet chiffrage et contrôle ponctuel du stock mais reste non confirmable. Les anciens paniers recette et leurs commandes de test sont conservés pour compatibilité et audit, sans être présentés comme des achats distincts dans la nouvelle interface. Les échecs de synchronisation sont repris sans perte silencieuse. Le sourcing opérationnel, le paiement, le raccordement à l'outil du livreur, l'index RAG et le contrat complet de passage de relais restent à construire avant tout pilote agentique.
Profils partenaires
Étend les contacts avec profils fournisseur, sites, foyer client, membres, préférences et consentements.
Compte client web
Inscription, connexion, profil, adresse, foyer, membres, préférences, consentements et panier produits unique par quantités, avec ajout direct ou groupé depuis une recette. Chiffrage et contrôle ponctuel du stock restent sans confirmation.
Catalogue métier
Étend les produits avec saisonnalité, provenance, poids variable, politique d’approvisionnement et cycle Référentiel → À sourcer → Pilote → Actif → Suspendu.
Suite recettes V1
Structure versions, ingrédients, calibres, rendements AP/EP, pesées locales, plans de repas, signaux de demande revus et projections Knowledge ; aucun prix, stock, achat automatique ou accès agent.
Corpus Knowledge
Gère les pages, catégories, étiquettes, révisions et approbations destinées au futur RAG.
Sourcing & exécution
Doit conserver disponibilités, sollicitations, validations d’achat, affectations, collecte, livraison directe et contrôle qualité.
| Information | Référentiel | Règle |
|---|---|---|
| Produit vendu | product.template | Une fiche commune, plusieurs offres possibles |
| Offre fournisseur | product.supplierinfo | Origine, prix, délai, site et conditionnement |
| Stock physique | stock.quant et mouvements | Uniquement un bien détenu ou contrôlé par DailyFresh |
| Contact et adresse | res.partner | Client et fournisseur ne sont pas exclusifs |
| Signal de demande recette | lepanier.recipe.demand.signal | Observation revue, jamais un achat automatique |
| Vente et achat | sale.order et purchase.order | Aucun document commercial parallèle |
| Photo ou preuve | ir.attachment | Reliée à sa source, son heure et sa validation |
Une quantité déclarée par un partenaire reste une preuve horodatée. Elle ne devient du stock Odoo qu’après réception ou prise de contrôle physique par DailyFresh.
Le runtime OpenClaw opérationnel est déployé, sain et privé. Il ne possède encore aucun canal client ou partenaire, aucun outil métier et aucun accès opérationnel à Odoo. La présence de ce runtime ne signifie pas que l’orchestrateur est actif.
Deux orchestrateurs
Séparer la promesse client de l’exécution terrain
| Orchestrateur | Responsabilités | Produit dans Odoo | Ne fait pas |
|---|---|---|---|
| Commercial | Détecter la langue, qualifier le foyer, consulter le RAG, composer une proposition, expliquer les estimations, recueillir les accords et informer le client | Demande qualifiée, proposition versionnée, contraintes, consentements et confirmation client | Ne promet pas une donnée expirée, ne choisit pas silencieusement un fournisseur et ne crée pas un achat ferme |
| Opérationnel | Choisir une branche d’exécution proposée, solliciter les partenaires, préparer les demandes d’achat, planifier collecte ou livraison directe et suivre les preuves | Plan d’exécution, sollicitations, réponses, missions, exceptions et résultat horodaté | Ne modifie pas seul la promesse client, ne valide pas un achat au MVP et n’invente pas une preuve terrain |
Actif dans l’environnement de développement
Un chef interne, une seule voix pour le client
L’assistant DailyFresh consulte un chef privé pour composer les menus selon le foyer autorisé, les préférences, le temps disponible, le budget et les objectifs déclarés. Le chef travaille à partir des recettes publiées ; sa proposition est vérifiée avant d’être reformulée au client. Cette analyse approfondie peut prendre près de deux minutes ; elle n’est pas instantanée.
Assistant DailyFresh
Conserve la conversation, les corrections consenties du foyer et l’ajout explicite au panier partagé.
Chef culinaire privé
Compose des repas et des variantes, sans outil d’écriture, envoi de message ou réponse directe au client.
Vérification métier
Relit recettes, portions, prix et disponibilités. Les courses regroupent les ingrédients avant les formats de vente ; la nutrition concerne les quantités consommées.
Les kcal et protéines sont estimées pour les repas couverts, avec les portions individuelles connues. Une cible énergétique est déclarée pour l’adulte concerné, jamais appliquée aux enfants. Les variantes restent non chiffrées et les conseils de conservation sont adaptés au repas.
La consultation ne sauvegarde pas de programme WhatsApp dans Ma semaine, ne modifie pas le panier et ne finalise aucune commande. Un stock lu n’est pas réservé : disponibilité réelle, services et créneau restent à confirmer pour la livraison choisie. Le lancement commercial et les notifications aux employés ne sont pas activés par ce lot.
Passage de relais
Un contrat structuré, versionné et idempotent
Le passage commercial → opérationnel est un objet Odoo, pas un simple message entre agents. Une notification peut réveiller le second orchestrateur, mais celui-ci relit toujours l’objet de référence avant d’agir.
Contenu minimal
- Identifiant de corrélation et clé d’idempotence
- Commande, version attendue et événement déclencheur
- Lignes, quantités, substitutions autorisées et contraintes
- Sources de disponibilité avec heure d’expiration
- Branche proposée, échéance et validations requises
Résultat minimal
- Accusé de prise en charge unique
- État courant et transitions journalisées
- Preuves partenaire et terrain reliées à leur source
- Exception codifiée ou demande de décision humaine
- Résultat final relisible par l’orchestrateur commercial
Une relance avec la même clé ne doit créer ni nouvelle commande, ni nouvel achat, ni nouvelle mission. Une modification fonctionnelle exige une nouvelle version et le contrôle de la version précédente.
Séparation
Production, IA, développement et documentation
| Environnement | Rôle | Garde-fou obligatoire |
|---|---|---|
| ERP de production | Référentiel opérationnel et protocole entre services | Accès nominatif, interfaces limitées, sauvegardes et journalisation |
| Console IA privée | Configuration et supervision des orchestrateurs | Accès restreint ; aucun parcours client avant validation métier |
| Mémoire conversationnelle privée | Contexte séparé par rôle d’orchestration | Active en test ; accord séparé, portée client et conservation de 30 jours glissants |
| Développement & recette | Console web noindex, catalogue Odoo, compte client, foyer, paniers, point GPS versionné, décision Harhoura, destination, tarif, créneaux, confirmation ponctuelle, réservation de stock, historique, préparation et suivi de remise actifs en test ; lecture multiappareil bornée | Aucune coordonnée ni preuve brute renvoyée ; aucun paiement, facture, achat fournisseur, raccordement livreur ou retrait client ; pas d'ouverture commerciale |
| Canaux B2C publics | Conversation, catalogue, recettes, panier et suivi | Accès aux données uniquement par des interfaces contrôlées |
| Documentation publique | Décisions et suivi partageables | Aucun secret, détail d’accès, identifiant interne ou donnée personnelle |
Le socle permanent est réparti en quatre stacks administrées séparément : l’ERP Odoo et sa file de travaux, le runtime de l’orchestrateur commercial, le runtime de l’orchestrateur opérationnel et de sa mémoire privée, puis le web de développement. Leurs cycles de vie restent indépendants afin qu’une intervention ciblée ne supprime ni les données ni les ressources des autres stacks.
Développement assisté
Un cadre Codex dédié protège chaque évolution
Le skill technique historique lepanier-dev-governance applique une même discipline aux changements de code, d’infrastructure, de données de référence et de documentation DailyFresh. Son nom reste inchangé pour compatibilité. Il complète les règles de chaque dépôt sans remplacer les arbitrages métier.
Préparer
Inspecter l’état Git, préserver les travaux existants, délimiter le changement et identifier les risques avant d’éditer.
Valider
Choisir les tests selon le risque, protéger les secrets et exiger baseline, sauvegarde et retour arrière pour la production.
Tracer
Mettre à jour les décisions et journaux durables, relire le diff puis isoler chaque changement cohérent dans un commit.
Ce skill n’accède pas aux clients ou fournisseurs et ne donne aucune autonomie supplémentaire aux orchestrateurs. Toute activation ou intervention de production conserve ses autorisations et validations propres.
Sécurité fonctionnelle
Garde-fous du MVP
- Toute disponibilité possède une source, une date de confirmation et une expiration.
- Toute contradiction produit l’état « confirmation requise ».
- Toute acceptation client qui engage la commande est journalisée.
- Toute écriture agentique porte une clé d’idempotence et contrôle la version attendue.
- Toute demande d’achat est validée par un humain au MVP.
- Un opérateur peut reprendre chaque conversation et chaque exception.
- Les secrets restent dans une gestion de configuration dédiée, jamais dans le site ou la documentation.
- Les connecteurs utilisent le minimum de droits et des identités techniques distinctes.
- Les appels externes sont idempotents ou protégés contre les doublons.
- Le mode développement ne contacte aucun vrai client, partenaire ou acteur de livraison.
- Les conversations privées du canal commercial sont ouvertes à tous les expéditeurs pour les essais, avec contexte client ; groupes et outils d’écriture métier restent désactivés.
- Le service Honcho est actif ; son raccordement aux conversations réelles exige encore la vérification de l’identité Odoo, du consentement, de la conservation, de la suppression et de la séparation entre clients.
Supervision
Autonomie à calibrer par le risque
La politique finale sera décidée après observation du pilote. Jusqu’alors, les actions irréversibles, les changements de montant, les substitutions sensibles, les litiges et les données ambiguës restent supervisés.
Informer et préparer
Détecter la langue, rechercher, résumer, calculer une estimation et demander les informations manquantes.
Proposer et coordonner
Solliciter un partenaire, proposer une branche ou préparer un achat selon des règles documentées.
Acheter et engager
Valider un achat, confirmer une variation, annuler, rembourser ou arbitrer un incident qualité.
Pilotage
Événements à mesurer dès le premier test
Conversation
Langue, intention, incompréhensions, transfert humain et abandon.
Fournisseurs
Temps de réponse, refus, correction photo, expiration et substitutions.
Opérations
Temps de collecte, écarts, consolidation, froid et incidents.
Client
Confirmation, changement de prix, livraison, paiement et satisfaction.
Économie
Achats, vente, coûts de collecte/livraison et marge lorsque définis.
Orchestrateurs
Passages de relais, rejouements, doublons évités, actions proposées, confirmées, corrigées et reprises.
Compte et foyer partagés · ADR-044
Un premier échange, un même compte
Déployé et vérifié en développement : le premier message WhatsApp retrouve ou crée le compte DailyFresh lié au contact Odoo. Le nom et la photo de profil sont récupérés lorsqu’ils sont accessibles, sans remplacer les informations déjà confirmées.
Un accueil simple
L’assistant retient si le client organise ses courses pour lui ou pour son foyer. Une demande précise reste prioritaire ; les questions déjà résolues ne sont pas répétées.
Un foyer réellement enregistré
Après accord, membres, portions et habitudes déclarées sont enregistrés dans Odoo. Le client retrouve et modifie le même foyer sur DailyFresh.
Un accès personnel
Un lien temporaire à usage unique ouvre le compte sans refaire une inscription. La photo reste privée. Le choix de livraison est disponible sans interrompre la connexion.
La photo dépend de sa visibilité sur WhatsApp. La mémoire des échanges exige un accord séparé. Cette ouverture ne sauvegarde pas encore le calendrier des repas et ne confirme aucune commande.