Chapitre 23 / 39

Ce à quoi l'IA peut accéder

Quand Rani, Paul ou Jack posent une question à l’IA, elle ne devine pas. Elle utilise des outils pour aller chercher la vraie réponse dans les données Sodimo — l’entrepôt Sodiwin, l’archive email et le CRM. Chacun de ces outils se trouve derrière un seul endpoint : un Cloudflare Worker appelé sodimo-core. Cet endpoint est le seul endroit où l’IA peut atteindre les systèmes Sodimo. Il n’y a pas de second endpoint sur le Framework Desktop, pas de contournement pour les agents on-prem, pas de raccourci.

MCP (le protocole commun que Claude utilise pour appeler les outils) répond toujours en anglais, par conception. Les alias email sodimo.eu existants sont conservés exactement tels quels — l’équipe ajoute et supprime des alias sur le serveur mail selon ses besoins.

Statut : Bloqué — les outils sont conçus. Ils seront opérationnels une fois le Framework Desktop en production, les données Sodiwin en flux vers l’entrepôt, et la bascule du serveur mail effectuée.

Un endpoint, une piste d’audit

Chaque surface IA chez Sodimo — une session Claude.ai, un agent planifié Paperclip, un skill invoqué depuis le terminal — atteint le même Cloudflare Worker. Une seule URL, protégée par Cloudflare Access avec Google Workspace comme fournisseur d’identité. Le Worker décide ce que chaque appelant est autorisé à faire. Le Worker écrit chaque appel dans le registre d’exécution.

Les humains accèdent aux services on-prem autrement : via l’interface web propre à chaque service, sur Tailscale. OpenWebUI pour le chat local. Piler pour la recherche email. Cockpit pour l’administration système. Pas d’indirection MCP pour les humains — l’interface native est déjà là, et c’est ce qu’un humain veut.

Cette séparation est structurante. Elle signifie que chaque effet secondaire causé par l’IA — chaque email envoyé, chaque note client écrite, chaque brouillon mis en queue — est enregistré en un seul endroit avec un seul schéma. « Montre-moi tous les emails que l’IA a envoyés la semaine dernière » est une seule requête, pas une agrégation de logs par surface.

Les outils que l’IA peut appeler

Pour référence, les outils que le Worker expose, par ordre alphabétique :

AR aging query — qui doit quoi, dans quel bucket
Approval-queue read — lettres en attente d’approbation par Paul
Catalog match — correspondance produit dans le catalogue Sodimo
Contract lookup — conditions des contrats enseignes, dates de renouvellement, exclusivités
Customer lookup — profil complet d’un client
Depot stock query — niveaux de stock par dépôt
Draft letter — lettre de relance au bon palier
Draft message — message de suivi à partir du contexte précédent
Email-send — voir la section circuit d’envoi ci-dessous
Email search — recherche dans l’archive complète par mot-clé, expéditeur, date, objet
Email thread read — lecture d’un fil de discussion complet
ETL status — état du chargement de données de la nuit précédente
Health check — Framework Desktop, mail, stack IA, ETL
Margin query — marge par client, enseigne ou période
Order history — toutes les commandes d’un compte donné
Order queue — mise en file d’une commande analysée pour saisie dans Sodiwin
Photo upload — photo attachée à une fiche client
Pricing lookup — tarif spécifique à un client
Revenue query — chiffre d’affaires par client, enseigne, commercial ou période
Run-ledger write — toute surface émet ici un enregistrement d’usage de tokens
Usage meter — usage IA du mois et escalades vers le cloud
Visit-note read / write — lecture ou écriture de notes de visite sur un client

Chaque appel effectué par l’IA est journalisé : qui, quel outil, quand, avec quels paramètres. Ce journal est consultable et constitue la base de la conformité CNIL et de l’audit de l’usage IA.

Le workflow de Rani — une journée en vente

Brief d’appel. Rani tape brief <client> avant un appel. L’IA remonte les cinq dernières commandes, la position AR, les notes de visite récentes, les produits principaux et le tarif client. Outils appelés : customer lookup, order history, AR snapshot, visit-note search, pricing lookup.

Visite client. Pendant la visite, Rani utilise le scanner de menu sur la carte d’un restaurant. Outils appelés : photo upload, catalog match, cross-sell suggestion.

Debrief de visite. Sur le trajet de retour, Rani ajoute une note via OpenWebUI (chapitre OpenWebUI) ou un skill de prise de note rapide ; la note est écrite sur la fiche client via l’outil visit-note. Outil appelé : visit-note write.

Note de vente additionnelle. Quand un plat ou un produit que Sodimo fournit est évoqué, une note est automatiquement attachée à la fiche client. Outil appelé : visit-note write.

Saisie de commande. Une commande capturée via OpenWebUI ou un skill de note rapide est analysée face au catalogue et mise en file pour saisie dans Sodiwin. Outils appelés : catalog match, order queue.

Planification de suivi. followup <client> rédige le prochain message à partir de la dernière note de visite et de la dernière commande. Outils appelés : visit-note read, order history, draft message.

Le workflow de Paul — une journée en finance

Brief du matin. À 07:00 Paul lit un email avec l’ancienneté des créances, le programme de paiement du jour, la file d’approbation des lettres de relance, et l’usage IA du mois. Outils appelés : AR aging query, approval-queue read, usage meter.

File de lettres de relance. Le système a rédigé les lettres overnight, une par client en retard au bon palier. Outils appelés : AR query, draft letter, queue write.

Approuver / modifier / envoyer. Paul ouvre la file, lit chaque brouillon, modifie si nécessaire, approuve. L’envoi part sous l’adresse de Paul. Outils appelés : queue read, draft edit, email-send.

Revue AR. En milieu de matinée, Paul pose à Claude.ai une question sur un client ou une enseigne spécifique. Outils appelés : AR query, order history, customer lookup.

Rapport mensuel. Une fois par mois, Paul génère le résumé pour Michel à partir de son modèle. Outils appelés : revenue query, margin query, AR snapshot, contract lookup, draft document.

Le workflow de Jack — une journée en opérations

Alertes opérationnelles. Le brief du matin remonte les alertes de la nuit — cron en échec, livraison lente, signal de santé système. Outils appelés : health check, log query.

Statut d’expédition. Jack demande des informations sur une commande ou un dépôt spécifique. Outils appelés : order lookup, depot stock query.

Santé système. En fin de journée ou à la demande, Jack vérifie l’état de la machine, du pipeline ETL et du serveur mail. Outils appelés : health check, ETL status, mail queue.

Le circuit d’envoi email

L’envoi d’email est l’exemple canonique de la façon dont le Worker atteint le serveur mail on-prem. Le Framework Desktop n’a aucun port entrant ouvert pour cela — Cloudflare ne pousse rien dans la machine. À la place, le Worker écrit l’envoi dans une Cloudflare Queue, et un petit service sur la machine tire depuis la queue, signe le message et le remet à Postfix.

Cinq propriétés de cette architecture sont importantes :

Aucun port entrant sur le Framework Desktop. La machine tire depuis la queue ; rien ne rentre. Le chemin mail est indépendant de tout tunnel Cloudflare.
Tolérant aux pannes. Si le Framework Desktop est hors ligne, les messages attendent dans la queue jusqu’à quatre jours et se drainent à son retour.
Limité en débit et relancé au niveau de la queue. Un agent incontrôlable rencontre la contre-pression de la queue, pas Postfix à plein régime. Les envois échoués sont relancés avec backoff et atterrissent dans une dead-letter queue s’ils épuisent les tentatives.
Une seule politique d’expéditeur. Que l’appelant soit Claude.ai ou un agent Paperclip tournant sur la même machine que Postfix, la liste d’expéditeurs autorisés du Worker est le seul contrôle. Deux politiques dérivent ; une seule politique ne dérive pas.
Une ligne d’audit par envoi. Le Worker écrit la ligne du registre d’exécution avant d’enqueue. Chaque email envoyé par l’IA est visible en une seule requête.

La synchronisation Paperclip → registre d’exécution suit la même architecture en sens inverse : Paperclip écrit dans son Postgres local, un cron sur le Framework Desktop synchronise les nouvelles lignes dans D1 via l’API HTTP D1. Pas de serveur MCP sur la machine, pas de port entrant, le Worker n’appelle pas le Framework Desktop.

Pourquoi pas un second endpoint MCP sur la machine

La question s’est posée pendant la conception — devrait-il y avoir un second endpoint MCP on-prem pour les outils qui vivent sur le Framework Desktop (modèles locaux, archive mail, logs système) ? La réponse est non. Candidat par candidat, il n’existe aucun outil qui à la fois (a) doit tourner on-prem pour des raisons de gravité des données, (b) doit être appelable par une IA plutôt que par un humain via une page web, et (c) ne peut pas être satisfait par une pull-queue. Piler a sa propre interface web pour les humains. Les modèles locaux sont derrière OpenWebUI pour les humains. Les logs système sont une tâche d’administration via ssh. L’outil email-send utilise le schéma pull-queue décrit ci-dessus.

Faire tourner un second endpoint ajouterait une pièce mobile qui doit suivre les changements upstream après la passation — exactement l’anti-pattern que les principes de conception signalent (chapitre Principes de conception). Un endpoint. Une piste d’audit. Aucun contournement.