Atelier équipe projet : portail métier, habilitations Google Workspace, workflows n8n et RAG QMD sécurisé.
Objectif : partir du terrain, créer le contexte statique, puis architecturer le serveur sans brûler les étapes.
INITIALISATION ATELIER
[1] garder Shopify stable OK
[2] utiliser Google Workspace OK
[3] recueillir SOP terrain 20 JUILLET → DÉBUT AOÛT
[4] créer contexte statique AVANT AUTOMATISATION
[5] cadrer serveur + Cloudron À VALIDER
[6] contrôler avant n8n NON NÉGOCIABLE
[7] cloisonner les RAG À DIMENSIONNER
TERRAIN
|
v
[SOP + irritants + workflows]
|
v
[CONTEXTE STATIQUE OKO]
|
v
[SERVEUR + PORTAIL + HARNAIS]
Cette présentation sert à aligner la direction, l'équipe projet et l'IT sur les choix techniques à prendre avant de construire. Le terrain vient avant le serveur.
Clarifier la cible de bout en bout, sans jargon inutile.
Lister les SOP métier, irritants, entrées, sorties et workflows candidats.
Valider les briques du pilote et les points bloquants.
Passer du contexte statique au serveur, au portail et aux automatisations.
Commandes, paiements et ventes restent stables pendant le pilote.
Les métiers commencent par des boutons, formulaires et SOP guidées.
SOP, fiches, règles, droits et sources utiles avant toute automatisation.
Le portail, n8n et les RAG viennent après le recueil des workflows prioritaires.
Le pilote doit prouver la valeur sans ouvrir des droits trop larges ni automatiser des décisions sensibles.
HORS PÉRIMÈTRE PILOTE NO chat libre généralisé NO n8n ouvert aux métiers NO RAG global non filtré NO lecture de mails collègues NO modification Shopify automatique NO remboursement automatique NO données marges dans workflows terrain YES lecture contrôlée YES brouillons à valider YES logs complets YES droits révoquables
DROITS EFFECTIFS UTILISATEUR ∩ WORKFLOW ∩ DONNÉE = ce que le système peut réellement utiliser
Même si Jan a accès à tout, un workflow SAV ne doit pas injecter les marges ou les investisseurs dans une réponse client.
Ce scénario peut être SAV, commercial, compta ou logistique. Le principe reste identique : login, droits, bouton, résultat, validation.
Service : exemple métier
Connexion via Google Workspace, sans nouveau compte à mémoriser.
Préparer, résumer, alerter, classer, demander.
Brouillons, rapports, listes d'actions et sources utilisées.
Les salariés ne manipulent pas les workflows.
Le routage IA est défini par l'équipe projet.
Obsidian reste outil direction, IT ou équipe projet si utile.
Elle transforme les SOP terrain en automatisations contrôlées, observe les logs et améliore les workflows.
Création, test, versioning, suspension.
Réécriture, garde-fous, format des sorties.
Périmètres documentaires et index autorisés.
Suivi des erreurs, modèles, tokens et validations.
Si l'architecture est claire pour l'IT mais confuse pour le terrain, elle ne sera pas adoptée. Si elle est simple pour le terrain mais floue pour l'IT, elle devient dangereuse.
CÔTÉ TERRAIN portail boutons formulaires résultat à valider ------------------------------ CÔTÉ PROJET / IT droits webhooks signés workflows n8n RAG autorisés routage modèles logs et audit
Le serveur ne doit pas improviser. Il exécute seulement des workflows issus des SOP recueillies, dans les droits Google et les sources autorisées.
Recueil SOP, règles métier, sources utiles, risques et validations.
Portail, gateway, n8n, QMD, IA gateway, logs et amélioration.
TERRAIN OKO
SOP / irritants / tâches répétitives
|
v
CONTEXTE STATIQUE
procédures + règles + fiches + sources
|
v
GOOGLE WORKSPACE
identité + groupes + révocation
|
v
PORTAIL MÉTIER
boutons + formulaires + résultats
|
v
GATEWAY D'HABILITATION
utilisateur ∩ workflow ∩ donnée
|
v
n8n
API + webhooks + orchestration
|
+--> Shopify [lecture]
+--> Gmail autorisé
+--> QMD / RAG autorisé
+--> Modèle IA routé
|
v
BROUILLON / RAPPORT / ALERTE
humain valide + log complet
La pédagogie à donner à l'IT : Cloudron héberge, Google identifie, le portail guide, la gateway autorise, n8n exécute, QMD cherche, l'IA produit, les logs prouvent.
Portail + boutons + demandes d'automatisation.
Cloudron + n8n + RAG + logs + gouvernance.
+----------------------------------+ | 8. LOGS / AUDIT / COÛTS | +----------------------------------+ | 7. IA GATEWAY | | modèles + clés + routage | +----------------------------------+ | 6. QMD / RAG CLOISONNÉS | +----------------------------------+ | 5. n8n | | workflows + connecteurs | +----------------------------------+ | 4. GATEWAY D'HABILITATION | +----------------------------------+ | 3. PORTAIL MÉTIER | +----------------------------------+ | 2. CLOUDRON / APPS | +----------------------------------+ | 1. GOOGLE WORKSPACE | | identité + groupes | +----------------------------------+
C'est un accélérateur d'exploitation : installer, mettre à jour, sécuriser et sauvegarder les apps du serveur.
| Cloudron gère | À garder ailleurs |
|---|---|
| Domaines et SSL | Droits fins workflows |
| Installation n8n, NocoDB, Gitea | RAG autorisés par rôle |
| Backups applicatifs | Accès boîtes mail |
| Groupes d'accès aux apps | Modèles IA par cas d'usage |
| Mises à jour | Validation humaine métier |
L'alternative est une installation manuelle ou Docker compose administré par l'IT. Cloudron accélère, mais impose son cadre.
La décision doit être explicite avant installation serveur.
Le cerveau conserve la connaissance. Le harnais exécute. Les secrets restent isolés.
/oko-memory/ 1_METIERS/ 2_SOCIETE/ 3_CLIENTS/ 4_PRODUITS/ 5_PROCESS/ 6_GARDEN/ /oko-automation/ workflows/ prompts/ skills/ schemas/ model-routing/ audit-logs/ credentials/ [isolé]
Le contexte statique OKO sert de couche de compréhension : SOP, fiches, synthèses, historiques utiles. Il ne devient pas la base officielle des ventes ou paiements.
C'est essentiel : le pilote commence en lecture et préparation, pas en mutation automatique du SI.
SOURCES DE VÉRITÉ
Shopify
commandes / paiements / produits vendus
|
| lecture contrôlée
v
Mémoire OKO
synthèses / SOP / dossiers reconstruits
^
| contexte statique
|
Google Workspace
identité / groupes / mails / Drive
RÈGLE PILOTE
préparer et expliquer : YES
modifier la source : NO
La révocation doit partir de Google Workspace : couper un compte ou un groupe coupe l'accès portail, workflows, mails et RAG associés.
portal.oko.fr
|
v
Connexion Google
|
v
email = sonia@oko.fr
groupes = oko-service-x
|
v
rôle portail
workflows visibles
RAG autorisés
boîtes mail accessibles
Les groupes doivent être assez fins pour protéger, mais pas tellement nombreux qu'ils deviennent ingérables.
Le pilote peut démarrer avec peu de groupes, puis affiner.
La règle : une boîte personnelle se lit avec le token OAuth de l'utilisateur connecté. Les boîtes de service se lisent selon les groupes Google.
UTILISATRICE : sonia@oko.fr GROUPES : oko-service-x AUTORISÉ sonia@oko.fr via OAuth Sonia service-x@oko.fr via groupe Google INTERDIT marc@oko.fr jan@oko.fr investisseurs@oko.fr Le backend recalcule la liste. Le formulaire ne choisit pas librement la mailbox.
Les métiers ne doivent pas accéder à n8n. Ils passent par le portail, puis une gateway appelle un webhook signé.
PORTAIL MÉTIER | | identité + rôle + demande v GATEWAY D'HABILITATION | | payload signé serveur à serveur v n8n WEBHOOK PRIVÉ | +-- API Shopify lecture +-- Gmail autorisé +-- QMD RAG autorisé +-- Modèle IA choisi v RÉSULTAT + LOG + VALIDATION
On ne part pas d'une idée vague de workflow. On part d'une tâche réelle : entrée, étapes, outils, sortie, erreur possible, validation nécessaire.
Fréquence, temps perdu, outils, données, exceptions, décision humaine.
Fiche SOP, score de priorité, workflow candidat et niveau de risque.
SOP MÉTIER OBSERVÉE
"Tous les matins je fais..."
|
v
FICHE SOP
entrée / étapes / outils / sortie
exceptions / risques / validation
|
v
SCORING
fréquence + gain + simplicité + risque
|
v
WORKFLOW CANDIDAT
déclencheur + données + RAG + modèle
|
v
n8n PILOTE
lecture seule + résultat validable
|
v
LOG + RETOUR TERRAIN
garder / améliorer / arrêter
Le premier métier reste ouvert à discussion. Le critère : valeur visible, risque faible, données accessibles, validation humaine simple.
SAV est un bon exemple, mais la décision doit rester collective.
Il est très adapté au pilote si les contenus sont en Markdown. Pour PDF, Word ou PowerPoint, on convertit d'abord avec MarkItDown ou Docling.
PDF / Word / Drive / Email
|
v
Conversion Markdown
|
v
/oko-memory/service-x/
|
v
qmd update
qmd embed
|
v
RAG service-x disponible
Un seul index global est plus simple sur le papier, mais dangereux si un filtre est oublié. Pour le pilote, on cloisonne par périmètre.
Un rôle peut ouvrir plusieurs RAG. Un workflow peut en limiter l'usage. L'intersection protège les réponses.
RAG SÉPARÉS rag-service-pilote -> SOP + cas métier rag-produits -> fiches + règles produit rag-commercial -> prospects + relances rag-compta -> factures + paiements rag-direction -> pilotage transverse rag-strategique -> marges / banque / investisseurs UTILISATEUR groupes Google -> RAG autorisés WORKFLOW besoin métier -> RAG nécessaires RÈGLE RAG utilisés = rôle ∩ workflow
| Rôle | RAG possibles | Remarque |
|---|---|---|
| Service pilote | rag-service + rag-produits | Seulement ce qui aide le métier |
| Commercial | rag-commercial + rag-produits | Prospects, relances, historiques autorisés |
| Compta | rag-compta | Factures, paiements, relances comptables |
| Direction | rag-service, rag-commercial, rag-compta, rag-produits, rag-direction | Vision transverse |
| Root | tous les RAG + rag-strategique | Jan / décision explicite |
Le choix dépend du premier workflow, des données disponibles et du niveau de risque accepté.
Recommandation : peu de RAG au départ, très bien cloisonnés.
| Risque | Garde-fou |
|---|---|
| Fuite entre RAG | Index séparés + gateway + logs |
| Lecture boîte collègue | OAuth utilisateur + recalcul serveur des mailbox autorisées |
| n8n exposé aux métiers | Portail obligatoire + webhooks signés |
| Action Shopify trop tôt | Lecture seule + validation humaine |
| Coûts IA non suivis | IA gateway + logs modèle et coût |
| Secrets dans le vault | Coffre + variables d'environnement + séparation automation |
Les logs servent autant à l'audit qu'à l'amélioration continue : comprendre les erreurs, mesurer la valeur, surveiller les coûts.
À LOGGER qui quoi quand workflow boîtes consultées RAG utilisés sources injectées modèle IA coût estimé résultat validation humaine erreur éventuelle
20 juillet à début août : observer, interviewer, recueillir SOP et workflows candidats.
Scorer les cas : fréquence, gain, risque, données disponibles, validation humaine.
Créer les fiches, règles, SOP, sources, arborescence et droits documentaires.
VPS, Cloudron ou alternative, domaines, SSL, backups et monitoring.
Google SSO, groupes, rôles, révocation et boîtes de service.
Catalogue d'actions, formulaires, gateway d'habilitation et demandes d'automatisation.
n8n, webhooks signés, connecteurs en lecture, logs et validation humaine.
QMD cloisonné, premier workflow, tests terrain et amélioration continue.
Du 20 juillet à début août, l'objectif n'est pas de vendre une solution figée. L'objectif est de comprendre les gestes métier, recueillir les SOP, puis architecturer le serveur sur les vrais besoins.
Les dates après début août sont indicatives et doivent être recalées avec OKO selon les arbitrages IT.
20 JUILLET
arrivée terrain / lancement cadrage
|
v
20 JUILLET -> DÉBUT AOÛT
observation métiers
interviews rapides
recueil SOP répétitives
inventaire workflows candidats
cartographie outils / mails / droits
|
v
DÉBUT AOÛT
synthèse des SOP
scoring des workflows
choix du ou des premiers pilotes
|
v
AOÛT - ARCHITECTURE
socle serveur + Cloudron ou alternative
Google Workspace / groupes / accès
contexte statique OKO
|
v
SEPTEMBRE - MVP TECHNIQUE
portail + gateway + n8n lecture seule
premiers RAG QMD
logs + validation humaine
|
v
PILOTE CONTRÔLÉ
2 à 5 utilisateurs
workflows validés
retour terrain + itérations
La synthèse reste locale dans le navigateur. Elle peut être copiée puis collée dans une note de réunion, un mail ou le projet OKO.
Réponses sauvegardées localement dans ce navigateur.