# MC Studio: full content > Every indexable page of https://mc-stud.io, as Markdown, French first then English. Each document starts with its own frontmatter (title, url, lang). Index: https://mc-stud.io/llms.txt --- title: "Matisse Chenavas, AI Adoption Lead et ingénieur" description: "Je suis Matisse Chenavas, AI Adoption Lead et ingénieur logiciel : je fais entrer l’IA et l’ingénierie agentique dans le travail réel des équipes." url: "https://mc-stud.io/" lang: "fr" updated: "2026-10-12" --- Bonjour, je suis Matisse Chenavas # Je fais passer l’IA du pilote au travail réel de vos équipes. - AI Adoption Lead - ingénieur logiciel - fondateur de MC Studio Avec vous, je choisis les bons cas d’usage J’aide les équipes à adopter l’IA sans casser ce qui marche : des cas d’usage mesurables, des données protégées, des agents intégrés à leurs méthodes et des personnes formées. Je livre du logiciel pour des organisations réelles depuis 2022, et je travaille moi-même chaque jour avec des agents. [Parler de votre projet](https://mc-stud.io/contact) [Voir les réalisations](https://mc-stud.io/realisations) ![Portrait de Matisse Chenavas.](https://mc-stud.io/_astro/01-hero-portrait.CTqtA5AW_1wswFE.jpg) Qui je suis ## Un ingénieur qui reste jusqu’à l’usage J’ai appris le métier en livrant. Formé à 42 Lyon, j’ai signé mon premier contrat de développeur en 2022. Depuis, je conçois des systèmes qui servent de vrais utilisateurs, le plus souvent intégré aux équipes de mes clients : une automatisation de dossiers SAV en production dans la santé, une application mobile et son back-office, un banc d’essai de lecture de documents sous contrainte de données de santé. En janvier 2026, j’ai fondé MC Studio pour porter ce travail sous mon nom. Mon terrain : l’IA opérationnelle et l’ingénierie agentique, là où la sécurité, la traçabilité et l’adoption comptent autant que le modèle. Je travaille chaque jour avec des agents, cadrés par des règles écrites, des skills et des workflows vérifiés ; ce site est construit ainsi. C’est cette méthode que j’apporte aux équipes que je rejoins, et quand un projet le demande, je peux réunir autour de moi une petite équipe d’indépendants choisis. **Premier contrat de développeur** 2022 **MC Studio, fondé en janvier** 2026 **Formé à** 42 Lyon **Langues de travail** FR · EN [Mon parcours](https://mc-stud.io/a-propos) Repères ## Quelques faits, vérifiables sur ce site **organisations clientes, en direct ou aux côtés de partenaires** 5 **dossiers de réalisation publiés, limites comprises** 9 **projets qui intègrent l’IA ou forment à l’IA** 7 **outils publiés sur GitHub pour travailler avec des agents, dont 5 en open source** 6 Chaque dossier et chaque outil compté ici est consultable sur ce site. Je livre du logiciel depuis 2022, et MC Studio existe depuis janvier 2026. Expertises ## Ce que le marché me demande d’abord L’IA opérationnelle et son adoption par les équipes ouvrent la liste : c’est là que les projets échouent le plus souvent, et là que je suis le plus utile. Le reste de la chaîne suit, parce qu’un agent sans données fiables ni application pour l’accueillir ne sert à rien. 1. Rôle phare ### [IA opérationnelle](https://mc-stud.io/expertises#ai) Quand l’IA a été testée sans critère ni cadre, et n’a jamais quitté le pilote. LLM, agents, RAG, OCR et modèles de vision, modèles open-weight ou hébergés chez vous : là où ils apportent une valeur mesurable, avec des frontières de données claires et une validation humaine. 2. Rôle phare ### [Adoption de l’IA et formation](https://mc-stud.io/expertises#adoption) Quand chacun bricole son assistant dans son coin, sans règle commune ni mesure. Faire passer l’IA d’essais isolés à une pratique d’équipe : règles d’usage, garde-fous, formation des développeurs à l’ingénierie agentique, relais internes et mesure de l’usage. 3. ### [Données et automatisation](https://mc-stud.io/expertises#data) Quand l’information existe mais n’arrive jamais au bon endroit. 4. ### [Applications métier sur mesure](https://mc-stud.io/expertises#applications) Quand Excel, les mails et les ressaisies tiennent lieu de système. 5. ### [Architecture, environnements et hébergement](https://mc-stud.io/expertises#architecture) Quand la dette technique et l’hébergement freinent chaque évolution. [Toutes les expertises](https://mc-stud.io/expertises) Intégration aux équipes ## Je m’intègre à votre équipe, puis j’augmente sa façon de travailler Je travaille le plus souvent dans les équipes de mes clients, sur des projets que je n’ai pas tous lancés. J’en ai tiré une méthode : rejoindre vos rituels d’abord, comprendre ce qui marche déjà, puis installer, à la mesure de l’équipe, les primitives de travail agentique que j’utilise chaque jour chez MC Studio. 1. ### Des règles écrites, pour les humains et les agents Un AGENTS.md, une fiche par projet, des décisions consignées. Le nouvel arrivant et l’agent lisent la même source, et elle se relit en revue comme du code. 2. ### Des savoir-⁠faire en skills Une procédure qui revient devient une skill que l’agent charge au bon moment. Chez moi, la préparation du compte rendu d’activité mensuel en est une, avec ses règles de vérification. 3. ### Des workflows en graphe, avec validation humaine Les tâches longues deviennent des graphes d’étapes, avec reprise et points de décision humains. C’est l’objet de pi-graph et de Zedflow, deux outils que je publie. 4. ### La preuve avant la confiance Tests, vérifications et revues font partie du flux. Un agent qui ne peut pas montrer ce qu’il a vérifié n’a pas terminé. Ce site est construit ainsi : plusieurs agents aux fichiers attribués, des consignes écrites, un build et une vérification de types à chaque passe, et ma relecture avant publication. [Voir mes outils open source](https://mc-stud.io/open-source) Réalisations ## Des dossiers de preuve, pas une galerie Chaque réalisation se lit d’une traite : l’essentiel en trente secondes, puis le récit, la preuve et les limites. 1. Santé, distribution de dispositifs médicaux 2024-2026 Via un partenaire IA ### [Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande](https://mc-stud.io/realisations/robotform-formulaires-sav) Les fiches de retour SAV de Santécie sont routées vers les bons formulaires fabricants et remplies automatiquement, avec une trace d’audit pour chaque demande. 2. Services numériques (ESN) 2026 En direct IA ### [Former des développeurs à l’ingénierie agentique, en huit séances](https://mc-stud.io/realisations/formation-ingenierie-agentique) Je prépare un parcours en huit séances, conçu pour faire passer des développeurs de l’usage ponctuel d’un assistant à une ingénierie agentique vérifiable, qui sait aussi s’en passer ; première séance le 16 octobre 2026. 3. Outillage d’agents IA 2026 Projet interne IA ### [Zedflow, des flux d’agents lisibles, composables et contrôlés](https://mc-stud.io/realisations/zedflow-flux-agents) Avec Zedflow, un flux d’agents se lit, se valide et se compose comme un programme, et les décisions sensibles attendent une validation humaine. [Toutes les réalisations](https://mc-stud.io/realisations) Clients et outils ## Avec qui et avec quoi je travaille ### Clients et partenaires - [Santécie](https://santecie.com/) - [Essan NFC](https://www.essannfc.com/) - [Silico](https://silico.fr/) - [Serial Coders](https://serialcoders.fr/) ### Technologies du quotidien - [TypeScript](https://www.typescriptlang.org/) - [React](https://react.dev/) - [NestJS](https://nestjs.com/) - [Prisma](https://www.prisma.io/) - [PostgreSQL](https://www.postgresql.org/) - [Python](https://www.python.org/) - [Rust](https://www.rust-lang.org/) - [Docker](https://www.docker.com/) - [Coder](https://coder.com/) - [Cloudflare](https://www.cloudflare.com/) - [Railway](https://railway.com/) - [Anthropic / Claude](https://www.anthropic.com/) - [LangChain](https://www.langchain.com/) - [Ollama](https://ollama.com/) - [vLLM](https://vllm.ai/) - [Hugging Face](https://huggingface.co/) - [NVIDIA](https://www.nvidia.com/) - [Astro](https://astro.build/) - [GitHub](https://github.com/) Chaque logo mène au site officiel de l’organisation ou du projet. Les marques appartiennent à leurs propriétaires. Pour les ESN et agences ## Mon expertise, au service de vos clients Vos clients vous demandent de l’IA et des agents, et vos équipes livrent déjà beaucoup. Je connais la sous-traitance de l’intérieur : votre client reste le vôtre, j’apporte la compétence qui vous manque, et je forme vos équipes pour qu’elles la gardent. [Travailler ensemble](https://mc-stud.io/partenaires) 1. Je ne prends pas votre terrain 2. J’apporte ce qui vous manque 3. Je forme vos développeurs Agents et open source ## Des outils pour les ingénieurs qui codent avec des agents Je publie les outils que je construis pour mon propre travail avec des agents : un moteur de flux d’agents, des extensions pour l’agent de code Pi, des skills, ma configuration de contexte. Chacun avec sa commande d’installation, ce qu’il fait et quand s’en servir. Bêta Pi contexte ### [pi-context-tree](https://mc-stud.io/open-source/pi-context-tree) Une extension pour l’agent de code Pi qui injecte le bon contexte au bon moment, selon le chemin et l’opération, à partir de fichiers CONTEXT.json versionnés dans le dépôt. **12** commits / 12 mois v0.4.2 `ZEDIUM-Off/pi-context-tree` Bêta Pi sous-agents ### [pi-runtime-monitor](https://mc-stud.io/open-source/pi-runtime-monitor) Une extension Pi légère qui affiche, dans le pied de page, le processeur, la mémoire et l’usage cumulé des sous-agents de votre session. **3** commits / 12 mois v0.1.1 `ZEDIUM-Off/pi-runtime-monitor` Expérimental skills planification ### [plan-writer](https://mc-stud.io/open-source/skills) Mes skills partagées pour agents, installables avec le CLI skills ; pour l’instant plan-⁠writer, qui aide à rédiger des plans d’implémentation structurés. **4** commits / 12 mois `ZEDIUM-Off/skills` [Tous les outils](https://mc-stud.io/open-source) Articles ## Notes de terrain Ce que j’apprends en livrant et en travaillant avec des agents : méthodes, retours d’expérience, limites. - 11 octobre 2026 5 min de lecture IA ### [Rejoindre une équipe, puis augmenter sa façon de travailler avec des agents](https://mc-stud.io/articles/rejoindre-une-equipe-et-y-installer-des-primitives-agentiques) Comment j’entre dans une équipe existante et j’y installe, à sa mesure, des primitives de travail agentique : contexte écrit, décisions consignées, skills, workflows avec validation humaine, preuve avant confiance. - 8 octobre 2026 6 min de lecture IA ### [Automatiser un processus sensible sans perdre la traçabilité](https://mc-stud.io/articles/automatiser-un-processus-sensible-sans-perdre-la-tracabilite) Automatiser un processus qui touche à la santé, à la paie ou à la facturation n’est pas une question de vitesse. C’est une question de mémoire : savoir, après coup, qui a décidé quoi, avec quelles règles et sur quelles données. [Tous les articles](https://mc-stud.io/articles) ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "Approche" description: "Je pars du métier réel, pas de la technologie : je rends la complexité lisible, puis je construis le système le plus simple qui répond au besoin." url: "https://mc-stud.io/approche" lang: "fr" updated: "2026-10-12" --- Approche # Clarifier pour décider, livrer pour agir Je pars du métier réel, pas de la technologie. Mon travail consiste à rendre la complexité lisible, puis à construire le système le plus simple qui satisfait le besoin complet. Vision ## Le travail augmenté, pas le travail remplacé Dans la plupart des organisations, une part considérable des journées consiste à imiter une machine : chercher une information, la copier, la ressaisir, relancer, consolider. Ces tâches ne demandent aucun jugement, et pourtant elles mobilisent des personnes compétentes. La technologie utile retire ces gestes mécaniques et rend aux équipes ce qui exige du discernement : comprendre un cas particulier, arbitrer, conseiller, entretenir une relation. C’est le critère que j’applique à chaque projet. Si un système ne libère pas de temps pour la décision, l’expertise ou la relation, il n’est pas encore le bon. La chaîne complète ## De la vision à la mesure, sans rupture Je tiens le fil de bout en bout. L’intention ne se perd pas entre celui qui cadre, celui qui développe et celui qui forme. 1. ### Comprendre Le métier, les frictions, les objectifs. 2. ### Structurer Les processus, les données, les priorités. 3. ### Concevoir Les parcours, l’architecture, les options. 4. ### Développer Un système solide, testé, documenté. 5. ### Sécuriser Les accès, les données, la conformité. 6. ### Déployer La mise en production et la supervision. 7. ### Faire adopter La formation et l’accompagnement. 8. ### Mesurer L’usage réel et l’impact métier. Méthode ## Quatre-vingt-dix jours, cinq décisions Chaque étape se termine par une décision explicite. Vous savez ce qui est livré, ce qui reste incertain et ce que vous décidez ensuite. 1. J0 à J10 ### Comprendre le réel Entretiens avec le terrain, observation des processus, inventaire des outils, des données et des contraintes. **Livrable** Synthèse projet et risques identifiés **Décision** Le problème mérite-t-il un système ? 2. J10 à J30 ### Cadrer et prioriser Options comparées, périmètre MVP, architecture cible, budget et critères de réussite. **Livrable** Périmètre MVP et options chiffrées **Décision** Quelle option lancer ? 3. J30 à J60 ### Prototyper ou piloter Un premier système utilisable, éprouvé avec de vrais utilisateurs et des données représentatives. **Livrable** Pilote en conditions réelles **Décision** Le pilote tient-il ses promesses ? 4. J60 à J90 ### Déployer, former, mesurer Mise en production, formation des équipes, premiers indicateurs d’usage et d’impact. **Livrable** Système en production et indicateurs **Décision** Étendre, ajuster ou arrêter ? 5. Ensuite ### Améliorer et transférer Stabilisation, documentation, transfert de compétences ou maintenance. **Livrable** Documentation et autonomie de vos équipes **Décision** Qui porte le système demain ? Lecture ## Comment lire un dossier Chaque dossier tient en cinq lignes, de l’enjeu aux limites ; le récit développe chacune. Les limites font partie de la preuve. 1. ### Enjeu Ce qui était en jeu pour le client, en une phrase. 2. ### Mécanisme Comment le système produit ce changement. 3. ### Preuve Ce qui le démontre : mesures, usages, éléments consultables sur demande. 4. ### Impact Ce que cela apporte au métier, en temps, en risque ou en qualité. 5. ### Limites Ce qui n’est pas démontré, ou reste à améliorer. Garde-fous ## Gouvernance, sécurité, mesure 1. ### Validation humaine requise Les décisions commerciales, juridiques, financières ou sensibles restent entre des mains humaines. Les systèmes préparent, les personnes tranchent. 2. ### Sécurité dès la conception Gestion des accès, cloisonnement des données, environnements reproductibles et traçabilité font partie du périmètre initial, pas d’un chantier ultérieur. 3. ### Mesure avant extension Chaque système livre ses propres indicateurs d’usage et d’impact, définis avant d’être mesurés. On étend ce qui fonctionne, on arrête ce qui ne fonctionne pas. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io) *** --- title: "Expertises" description: "Mes cinq expertises, de l’adoption de l’IA à l’architecture : chacune part d’un symptôme concret et se termine par un système en usage." url: "https://mc-stud.io/expertises" lang: "fr" updated: "2026-10-12" --- Expertises # De l’adoption de l’IA aux fondations qui la portent Cinq savoir-faire, classés par ce que les organisations me demandent d’abord. Les deux premiers forment le rôle d’AI Adoption Lead ; les trois suivants sont ce qui le rend possible. Le rôle que je propose AI Adoption Lead Faire passer l’IA d’essais isolés à un usage mesuré : choisir les cas d’usage, poser les frontières de données et d’accès, définir comment on évalue, outiller les équipes et les former, puis suivre l’adoption dans le temps. - Pilotes mesurables, avec critères d’acceptation - Garde-fous : données, accès, traçabilité - Formation et réseau de relais internes Un rôle que je propose en mission, adossé aux projets décrits dans mes réalisations. 1. [01 IA opérationnelle](https://mc-stud.io/expertises#ai) 2. [02 Adoption de l’IA et formation](https://mc-stud.io/expertises#adoption) 3. [03 Données et automatisation](https://mc-stud.io/expertises#data) 4. [04 Applications métier sur mesure](https://mc-stud.io/expertises#applications) 5. [05 Architecture, environnements et hébergement](https://mc-stud.io/expertises#architecture) Rôle phare ## IA opérationnelle LLM, agents, RAG, OCR et modèles de vision, modèles open-weight ou hébergés chez vous : là où ils apportent une valeur mesurable, avec des frontières de données claires et une validation humaine. Le symptôme Quand l’IA a été testée sans critère ni cadre, et n’a jamais quitté le pilote. Ce que je livre - Cas d’usage choisis sur un critère de réussite écrit - Bancs d’essai comparatifs avant tout choix de modèle ou de fournisseur - Assistants et agents bornés, avec validation humaine - Hébergement privé ou local quand les données l’exigent Outils typiques - LLM - Agents - RAG - OCR et VLM - Modèles open-weight - Évaluation Preuves associées 1. Santé, distribution de dispositifs médicaux 2024-2026 Via un partenaire IA ### [Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande](https://mc-stud.io/realisations/robotform-formulaires-sav) Les fiches de retour SAV de Santécie sont routées vers les bons formulaires fabricants et remplies automatiquement, avec une trace d’audit pour chaque demande. 2. Services numériques (ESN) 2026 En direct IA ### [Former des développeurs à l’ingénierie agentique, en huit séances](https://mc-stud.io/realisations/formation-ingenierie-agentique) Je prépare un parcours en huit séances, conçu pour faire passer des développeurs de l’usage ponctuel d’un assistant à une ingénierie agentique vérifiable, qui sait aussi s’en passer ; première séance le 16 octobre 2026. [Voir les 6 dossiers dans les réalisations](https://mc-stud.io/realisations) Rôle phare ## Adoption de l’IA et formation Faire passer l’IA d’essais isolés à une pratique d’équipe : règles d’usage, garde-fous, formation des développeurs à l’ingénierie agentique, relais internes et mesure de l’usage. Le symptôme Quand chacun bricole son assistant dans son coin, sans règle commune ni mesure. Ce que je livre - Cadre d’usage : données autorisées, accès, traçabilité - Parcours développeurs en ingénierie agentique, sur vos dépôts - Primitives d’équipe : AGENTS.md, skills, workflows vérifiés - Indicateurs d’adoption définis avant le déploiement Outils typiques - Ateliers - Travaux pratiques - AGENTS.md - Skills - Mesure d’usage Preuves associées 1. Services numériques (ESN) 2026 En direct IA ### [Un environnement de développement maîtrisé, prêt pour coder avec l’IA](https://mc-stud.io/realisations/environnements-de-developpement-coder) Les développeurs de Silico disposent d’environnements standardisés, décrits en code et hébergés sur une infrastructure maîtrisée, socle d’un usage encadré de l’IA. [Voir les 2 dossiers dans les réalisations](https://mc-stud.io/realisations) ## Données et automatisation Relier les données dispersées, automatiser ce qui doit l’être, et garder la trace de chaque décision prise par le système. Le symptôme Quand l’information existe mais n’arrive jamais au bon endroit. Ce que je livre - Cartographie des flux et des sources - Routage, files de traitement et automatisations - Traces d’exécution et reprise sans doublon - Indicateurs d’impact définis avant d’être mesurés Outils typiques - SQL - [Python](https://www.python.org/) - [PostgreSQL](https://www.postgresql.org/) - BullMQ - Windmill - API Preuves associées 1. Santé, distribution de dispositifs médicaux 2024-2026 Via un partenaire IA ### [Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande](https://mc-stud.io/realisations/robotform-formulaires-sav) Les fiches de retour SAV de Santécie sont routées vers les bons formulaires fabricants et remplies automatiquement, avec une trace d’audit pour chaque demande. ## Applications métier sur mesure Des outils internes taillés pour vos processus réels : traitement de dossiers, formulaires et validations, back-offices, applications mobiles, portails d’administration. Le symptôme Quand Excel, les mails et les ressaisies tiennent lieu de système. Ce que je livre - Cadrage des processus et du périmètre MVP - Conception des parcours avec les équipes terrain - Développement full-stack, web et mobile - Mise en production, documentation et transfert Outils typiques - [TypeScript](https://www.typescriptlang.org/) - Vue.js - [NestJS](https://nestjs.com/) - [Prisma](https://www.prisma.io/) - React Native - [PostgreSQL](https://www.postgresql.org/) Preuves associées 1. Sport et coaching 2025-2026 Via un partenaire IA ### [Faire d’une méthode d’entraînement une application mobile et son back-office](https://mc-stud.io/realisations/nfc-training-application-mobile) La méthode NFC existe sous forme de produit : une application mobile pour les pratiquants et un back-office pour l’équipe, sur un socle commun. 2. Protection sociale, caisse de congés payés 2024-2025 Via un partenaire ### [Une application de demandes de congés payés pour CICP2R](https://mc-stud.io/realisations/cicp-demandes-de-conges) Côté employeur, les demandes de congés payés et les jours à payer se saisissent dans une application dédiée, puis passent par une validation explicite. [Voir les 4 dossiers dans les réalisations](https://mc-stud.io/realisations) ## Architecture, environnements et hébergement Des fondations qui tiennent dans la durée : architecture, environnements de développement reproductibles, déploiement, maintenance et documentation, avec la sécurité prise en compte dès le départ. Le symptôme Quand la dette technique et l’hébergement freinent chaque évolution. Ce que je livre - Audit d’architecture et décisions consignées - Environnements de développement décrits en code - Intégration au système d’information existant - Déploiement, supervision et maintenance Outils typiques - [Docker](https://www.docker.com/) - Terraform - [Coder](https://coder.com/) - [Railway](https://railway.com/) - [Cloudflare](https://www.cloudflare.com/) - CI/CD Preuves associées 1. Outillage d’agents IA 2026 Projet interne IA ### [Zedflow, des flux d’agents lisibles, composables et contrôlés](https://mc-stud.io/realisations/zedflow-flux-agents) Avec Zedflow, un flux d’agents se lit, se valide et se compose comme un programme, et les décisions sensibles attendent une validation humaine. 2. Santé, complémentaire santé 2026 Via un partenaire IA ### [Choisir un moteur de lecture de cartes santé sur des preuves, pas sur une démo](https://mc-stud.io/realisations/scie-ocr-cartes-complementaire-sante) Le choix d’un moteur de lecture des cartes de complémentaire santé repose sur un banc d’essai reproductible, pas sur une démonstration commerciale. [Voir les 5 dossiers dans les réalisations](https://mc-stud.io/realisations) ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "Réalisations" description: "Mes dossiers de preuve : des projets réels menés en direct ou chez un partenaire, avec l’essentiel en trente secondes, puis la preuve et les limites." url: "https://mc-stud.io/realisations" lang: "fr" updated: "2026-10-12" --- Réalisations · 9 dossiers # Des dossiers de preuve Des projets réels, menés en direct ou au sein des équipes d’un partenaire pour ses clients finaux. Chaque dossier donne l’essentiel en trente secondes, puis le récit, la preuve et les limites. Clients - [Santécie](https://santecie.com/) - [Silico](https://silico.fr/) - [Essan NFC](https://www.essannfc.com/) Santécie 2024-2026 IA En production ## [Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande](https://mc-stud.io/realisations/robotform-formulaires-sav) Les fiches de retour SAV de Santécie sont routées vers les bons formulaires fabricants et remplies automatiquement, avec une trace d’audit pour chaque demande. **Enjeu** Chaque retour SAV doit partir vers le fabricant sur son propre formulaire ; la recopie manuelle prenait du temps et exposait à des erreurs coûteuses. **Impact** La saisie devient de la configuration : au moins 500 heures évitées par tranche de 10 000 demandes, et un échec se rejoue isolément. Via un partenaire Lire le dossier Silico 2026 IA En préparation ## [Former des développeurs à l’ingénierie agentique, en huit séances](https://mc-stud.io/realisations/formation-ingenierie-agentique) Je prépare un parcours en huit séances, conçu pour faire passer des développeurs de l’usage ponctuel d’un assistant à une ingénierie agentique vérifiable, qui sait aussi s’en passer ; première séance le 16 octobre 2026. En direct Lire le dossier 2026 IA Pilote ## [Zedflow, des flux d’agents lisibles, composables et contrôlés](https://mc-stud.io/realisations/zedflow-flux-agents) Avec Zedflow, un flux d’agents se lit, se valide et se compose comme un programme, et les décisions sensibles attendent une validation humaine. Projet interne Lire le dossier Santécie 2026 IA Démonstrateur ## [Choisir un moteur de lecture de cartes santé sur des preuves, pas sur une démo](https://mc-stud.io/realisations/scie-ocr-cartes-complementaire-sante) Le choix d’un moteur de lecture des cartes de complémentaire santé repose sur un banc d’essai reproductible, pas sur une démonstration commerciale. Via un partenaire Lire le dossier Silico 2026 IA ## [Un environnement de développement maîtrisé, prêt pour coder avec l’IA](https://mc-stud.io/realisations/environnements-de-developpement-coder) Les développeurs de Silico disposent d’environnements standardisés, décrits en code et hébergés sur une infrastructure maîtrisée, socle d’un usage encadré de l’IA. En direct Lire le dossier Essan NFC 2025-2026 IA En pause ## [Faire d’une méthode d’entraînement une application mobile et son back-office](https://mc-stud.io/realisations/nfc-training-application-mobile) La méthode NFC existe sous forme de produit : une application mobile pour les pratiquants et un back-office pour l’équipe, sur un socle commun. Via un partenaire Lire le dossier 2026 IA Démonstrateur ## [Une mémoire partagée entre agents, cloisonnée par rôle](https://mc-stud.io/realisations/memoire-agents-cloisonnee) Plusieurs agents s’appuient sur une mémoire en graphe commune, sans qu’aucun n’accède au périmètre d’un autre. Projet interne Lire le dossier 2024-2025 ## [Une application de demandes de congés payés pour CICP2R](https://mc-stud.io/realisations/cicp-demandes-de-conges) Côté employeur, les demandes de congés payés et les jours à payer se saisissent dans une application dédiée, puis passent par une validation explicite. Via un partenaire Lire le dossier 2026 ## [Relier les mâts LumiSafe à une passerelle logicielle, pour la sécurité des voies ferrées](https://mc-stud.io/realisations/lumisafe-signalisation-mats) Les mâts LumiSafe dialoguent avec une passerelle logicielle par un protocole série qui évolue sans casser les mâts restés sur une version antérieure. Via un partenaire Lire le dossier Lecture ## Comment lire un dossier Chaque dossier tient en cinq lignes, de l’enjeu aux limites ; le récit développe chacune. Les limites font partie de la preuve. 1. ### Enjeu Ce qui était en jeu pour le client, en une phrase. 2. ### Mécanisme Comment le système produit ce changement. 3. ### Preuve Ce qui le démontre : mesures, usages, éléments consultables sur demande. 4. ### Impact Ce que cela apporte au métier, en temps, en risque ou en qualité. 5. ### Limites Ce qui n’est pas démontré, ou reste à améliorer. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io) *** --- title: "Articles" description: "Mes notes de terrain : méthodes, retours d’expérience et limites observées en livrant des systèmes métier et en travaillant avec des agents." url: "https://mc-stud.io/articles" lang: "fr" updated: "2026-10-12" --- Articles # Notes de terrain Méthodes, retours d’expérience et limites observées en livrant des systèmes métier et en travaillant avec des agents. 11 octobre 2026 5 min de lecture Adoption IA ## [Rejoindre une équipe, puis augmenter sa façon de travailler avec des agents](https://mc-stud.io/articles/rejoindre-une-equipe-et-y-installer-des-primitives-agentiques) Comment j’entre dans une équipe existante et j’y installe, à sa mesure, des primitives de travail agentique : contexte écrit, décisions consignées, skills, workflows avec validation humaine, preuve avant confiance. - J’entre dans une équipe par ses rituels et son code, pas par mes outils. - Les premières primitives sont des textes : un fichier de contexte, des décisions consignées, un glossaire. Humains et agents lisent la même source. - Une procédure qui revient devient une skill ; une tâche longue devient un graphe avec des validations humaines. 8 octobre 2026 6 min de lecture Données IA ## [Automatiser un processus sensible sans perdre la traçabilité](https://mc-stud.io/articles/automatiser-un-processus-sensible-sans-perdre-la-tracabilite) Automatiser un processus qui touche à la santé, à la paie ou à la facturation n’est pas une question de vitesse. C’est une question de mémoire : savoir, après coup, qui a décidé quoi, avec quelles règles et sur quelles données. 1er octobre 2026 5 min de lecture IA opérationnelle IA ## [De l’idée au pilote : réussir un projet IA mesurable](https://mc-stud.io/articles/de-l-idee-au-pilote-reussir-un-projet-ia-mesurable) La plupart des projets d’IA ne meurent pas d’un mauvais modèle. Ils meurent d’un pilote sans critère de réussite. Voici comment je construis un pilote qui permet de décider. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io) *** --- title: "Agents et open source" description: "Les extensions, skills et outils que je construis pour travailler avec des agents de code, publiés tels quels : usage, installation, code source." url: "https://mc-stud.io/open-source" lang: "fr" updated: "2026-10-12" --- Agents et open source # Des outils pour coder avec des agents Les extensions, skills et outils que je construis pour mon propre travail avec des agents de code, publiés tels quels : ce qu’ils font, quand s’en servir, comment les installer. [github.com/ZEDIUM-Off](https://github.com/ZEDIUM-Off) 708 **commits sur 12 mois** 6 **dépôts publics** 11 octobre 2026 **dernière mise à jour** 1 **étoile GitHub** Chiffres GitHub relevés le 12 octobre 2026. Bêta Pi contexte ## [pi-context-tree](https://mc-stud.io/open-source/pi-context-tree) Une extension pour l’agent de code Pi qui injecte le bon contexte au bon moment, selon le chemin et l’opération, à partir de fichiers CONTEXT.json versionnés dans le dépôt. **12** commits / 12 mois v0.4.2 `ZEDIUM-Off/pi-context-tree` Bêta Pi sous-agents ## [pi-runtime-monitor](https://mc-stud.io/open-source/pi-runtime-monitor) Une extension Pi légère qui affiche, dans le pied de page, le processeur, la mémoire et l’usage cumulé des sous-agents de votre session. **3** commits / 12 mois v0.1.1 `ZEDIUM-Off/pi-runtime-monitor` Expérimental skills planification ## [plan-writer](https://mc-stud.io/open-source/skills) Mes skills partagées pour agents, installables avec le CLI skills ; pour l’instant plan-⁠writer, qui aide à rédiger des plans d’implémentation structurés. **4** commits / 12 mois `ZEDIUM-Off/skills` Expérimental flux d’agents Rust ## [Zedflow](https://mc-stud.io/open-source/zedflow) Un moteur et un studio locaux pour des flux d’agents typés : chaque flux est un graphe validé avant exécution, avec contexte maîtrisé, validations humaines et trace de chaque tour. **678** commits / 12 mois v0.2.0 `ZEDIUM-Off/zedflow` Bêta CLI comptabilité ## [pennylane-cli](https://mc-stud.io/open-source/pennylane-cli) Un CLI pensé pour les agents, qui expose l’API Pennylane v2 en commandes à sortie JSON, avec une porte de sortie pour les requêtes brutes. **2** commits / 12 mois v0.1 `ZEDIUM-Off/pennylane-cli` Expérimental Pi contexte ## [.pi](https://mc-stud.io/open-source/pi-config) Ma configuration de contexte Pi, dans sa partie publique : des normes compactes pour agents (responsabilité, contrats, exécution, piles techniques), injectées par pi-⁠context-⁠tree. **9** commits / 12 mois v0.1.0 · 1 ★ `ZEDIUM-Off/.pi` ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "ESN et agences : mon expertise pour vos clients" description: "Pour les ESN et agences : je viens compléter vos équipes sous votre pilotage, au service de vos clients, et je laisse la compétence chez vous." url: "https://mc-stud.io/partenaires" lang: "fr" updated: "2026-10-12" --- Pour les ESN et agences # Mon expertise, au service de vos clients Vos clients vous demandent de l’IA, des agents, de l’automatisation. Vos équipes livrent déjà beaucoup. Je viens compléter, sous votre pilotage, et je laisse la compétence chez vous en partant. ## Ce que je m’engage à faire, et à ne pas faire 1. ### Je ne prends pas votre terrain Votre client reste le vôtre. Je travaille dans votre cadre contractuel, avec vos rituels et vos interlocuteurs, et je ne démarche pas vos clients. 2. ### J’apporte ce qui vous manque IA opérationnelle, agents, RAG, OCR, modèles locaux, ingénierie agentique pour les développeurs : la compétence rare qui débloque un projet ou renforce une réponse à appel d’offres. 3. ### Je forme vos équipes Ateliers et travaux pratiques sur vos propres dépôts, pour que vos développeurs gardent la méthode après mon départ. ## Comment on peut travailler ensemble - ### Renfort sur un projet client Je rejoins l’équipe projet sur une phase précise : cadrage IA, architecture, pilote, mise en production. - ### Avant-vente et cadrage Je vous aide à qualifier un besoin IA, à chiffrer une option et à écrire ce qui est promis, sans survendre. - ### Formation de vos développeurs Un parcours en ingénierie agentique : règles écrites pour les agents, skills, workflows, vérification, sécurité des données. ## Ce que je fais déjà dans ce cadre Une grande part de mes projets s’est faite dans ce cadre, avec plusieurs partenaires : intégré à l’équipe d’un partenaire ou en renfort sous son pilotage, pour ses clients finaux. - Une automatisation de dossiers SAV en production pour un distributeur de dispositifs médicaux - Une application mobile et son back-office pour une méthode d’entraînement - Un banc d’essai de lecture de documents sous contrainte de données de santé - Le logiciel de mâts de sécurité pour la maintenance ferroviaire Je conçois aussi des parcours de formation à l’ingénierie agentique pour les développeurs. Chaque dossier nomme le client final ; le cadre de la mission figure dans sa fiche. [Lire les dossiers](https://mc-stud.io/realisations) ## Un client, un besoin, une compétence qui manque ? Parlons du projet et du cadre. Je vous dis vite si je suis la bonne personne. [Proposer une collaboration](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Collaboration%20ESN%20ou%20agence) *** --- title: "À propos de Matisse Chenavas" description: "Ingénieur logiciel et fondateur de MC Studio, je relie la vision d’une direction aux réalités du terrain et je fais adopter l’IA par les équipes." url: "https://mc-stud.io/a-propos" lang: "fr" updated: "2026-10-12" --- À propos # Matisse Chenavas - AI Adoption Lead - ingénieur logiciel - fondateur de MC Studio Je relie la vision d’une direction aux réalités du terrain, puis je construis ce qui manque entre les deux. En ce moment, c’est surtout l’IA : la faire adopter, proprement, par des équipes qui ont déjà beaucoup à faire. - [LinkedIn](https://www.linkedin.com/in/matisse-chenavas) - [GitHub](https://github.com/ZEDIUM-Off) - [contact@mc-stud.io](mailto:contact@mc-stud.io) ![Portrait de Matisse Chenavas.](https://mc-stud.io/_astro/01-hero-portrait.CTqtA5AW_1wswFE.jpg) Parcours ## Mon parcours 1. 2021 ### Une année d’informatique à l’IUT Lyon 1 Le point de départ, avant de choisir l’apprentissage par projets. 2. 2022 à 2025 ### Formé à 42 Lyon La piscine, puis le tronc commun : apprendre par les pairs et par les projets. 3. 2022 ### Premier contrat de développeur Un CDD de développeur API, en octobre et novembre : ma première mission payée. 4. Depuis 2023 ### Ingénieur logiciel et IA indépendant Applications métier, automatisation, lecture de documents, environnements de développement et formation à l’ingénierie agentique, le plus souvent intégré aux équipes de mes clients. En micro-entreprise jusqu’en 2025, puis via MC Studio. 5. 2024 à 2026 ### Fondateur de HIGHFINITY Une première entreprise, de novembre 2024 à mai 2026. 6. Depuis 2026 ### MC Studio Mon studio, fondé en janvier 2026 pour porter l’IA opérationnelle et l’ingénierie agentique sous mon nom. ## En ce moment - Je prépare un programme en huit séances pour former des développeurs à l’ingénierie agentique. - Je construis Zedflow, un moteur de flux d’agents typés, et je m’en sers pour mes propres opérations. - Je publie le code des outils que j’utilise pour coder avec des agents. Ma façon de travailler ## Dans votre équipe, ou une petite équipe autour du projet La plupart de mes projets se sont faits dans des équipes que je n’avais pas constituées, aux côtés de leurs développeurs. C’est le cadre que je connais le mieux : je rejoins vos rituels, j’apporte cadrage, architecture et IA, et j’outille l’équipe avec des méthodes de travail agentique qu’elle garde après mon départ. Dans tous les cas, vous avez un interlocuteur qui dit ce qui est prouvé, ce qui ne l’est pas encore, et qui répond de ce qu’il livre. 1. ### Intégré à votre équipe Je rejoins l’équipe projet, ses outils et ses rituels, et je livre avec elle. C’est le cadre de la plupart de mes missions depuis 2023. 2. ### Des méthodes agentiques installées chez vous Règles écrites pour les humains et les agents, skills, workflows avec validation humaine, vérification systématique : je mets en place ce qui sert l’équipe, et je la forme à s’en servir. 3. ### Une petite équipe, si le projet l’exige Pour un projet plus large, je peux réunir autour de moi quelques indépendants choisis pour leur spécialité, avec un périmètre et des livrables écrits. Je fixe l’architecture, je relis ce qui part en production et je reste votre interlocuteur. Principes ## Ce qui guide mon travail 1. ### La justesse avant l’effet Je préfère une solution simple et vérifiée à une démonstration impressionnante. 2. ### La transparence sur les limites Je dis ce qui est démontré, ce qui est supposé et ce qui reste à vérifier. 3. ### L’humain dans la boucle Les systèmes préparent et accélèrent. Les décisions engageantes restent humaines. 4. ### Le transfert Je documente les décisions et je forme les équipes pour qu’elles restent autonomes. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "Contact" description: "Décrivez-moi ce qui bloque, même de façon floue. Je reviens vers vous avec une première lecture et, si c’est pertinent, un créneau pour en parler." url: "https://mc-stud.io/contact" lang: "fr" updated: "2026-10-12" --- Contact # Parlons de votre projet Décrivez-moi ce qui bloque, même de façon floue. Je reviens vers vous avec une première lecture et, si c’est pertinent, un créneau pour en parler. ## Par email Le plus simple pour démarrer. Quelques lignes suffisent. [contact@mc-stud.io](mailto:contact@mc-stud.io) Je lis chaque message moi-même et je réponds sous deux jours ouvrés. ## Échange découverte (30 min) Pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. En visio, sans engagement. Les créneaux viennent directement de mon agenda. [Choisir un créneau](https://calendar.app.google/VQTPrCgNvQSNwdA7A) ## Pour un premier échange utile - Le contexte : votre organisation, l’équipe concernée, les outils en place. - Le symptôme : ce qui prend trop de temps, se perd ou se répète. - L’échéance : ce qui rend le sujet urgent ou important maintenant. Basé près de Lyon, j’interviens sur site et à distance, en français et en anglais. **Vous êtes une ESN ou une agence ?** Je travaille aussi au service des clients de mes partenaires, sans jamais prendre leur place. [Voir comment](https://mc-stud.io/partenaires) - [LinkedIn](https://www.linkedin.com/in/matisse-chenavas) - [GitHub](https://github.com/ZEDIUM-Off) *** --- title: "Former des développeurs à l’ingénierie agentique, en huit séances" description: "Je prépare pour Silico un programme de formation conçu pour faire passer des développeurs de l’usage ponctuel d’un assistant à une pratique d’ingénierie agentique vérifiable : contexte, délégation bornée, vérification, sécurité. Première séance le 16 octobre 2026." url: "https://mc-stud.io/realisations/formation-ingenierie-agentique" author: "Matisse Chenavas" date: "2026-10-09" lang: "fr" ai: "true" --- # Former des développeurs à l’ingénierie agentique, en huit séances > Je prépare un parcours en huit séances, conçu pour faire passer des développeurs de l’usage ponctuel d’un assistant à une ingénierie agentique vérifiable, qui sait aussi s’en passer ; première séance le 16 octobre 2026. - **Client**: Silico - **Secteur**: Services numériques (ESN) - **Période**: 2026 - **Mon rôle**: Concepteur du programme et formateur - **Cadre**: En direct - **Équipe**: Seul · 1 personne - **Statut**: En préparation - **Technologies**: Git, GitHub, Ateliers, Travaux pratiques, Évaluation - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Les développeurs utilisent déjà l’IA chacun à sa façon ; il manque une pratique commune, que l’on peut enseigner, vérifier et expliquer à la direction. - **Mécanisme** : Huit après-midi, chacune suivie d’un exercice autonome sur un cas fil rouge fictif, du contexte à la délégation bornée puis à la vérification. - **Preuve** : Huit présentations rendues, un socle réutilisable de dix-sept unités et une orientation acceptée par Silico le 9 octobre 2026. - **Impact** : L’équipe disposera d’une base commune pour encadrer l’IA dans le code, au lieu d’une juxtaposition de pratiques individuelles. - **Limites** : La première séance a lieu le vendredi 16 octobre 2026 : aucun résultat d’apprentissage n’est encore mesuré. ## Indicateurs - 8 séances d’un après-midi, chacune suivie d’un exercice - 138 diapositives rendues, avec notes orales - 17 unités dans le socle réutilisable ## Le point de départ Dans beaucoup d'équipes, l'IA est déjà là, mais chacun l'utilise à sa façon. Certains développeurs doutent de la fiabilité des agents, d'autres craignent de perdre ce qui fait leur métier, et la direction ne sait pas très bien ce qui se passe dans les dépôts. Ni l'interdiction ni l'enthousiasme ne règlent la question. ## Ce que j'ai conçu Chaque séance alterne présentation et démonstration, puis se prolonge par un exercice à réaliser en autonomie avant la suivante. Tous les exercices portent sur le même cas fil rouge, une entreprise fictive : on peut tout montrer, tout casser et tout corriger sans toucher au code d'un client. Le parcours suit une progression simple : comprendre les limites d'un modèle, lui fournir le contexte pertinent, lui déléguer une tâche bornée, vérifier le résultat de façon indépendante, diagnostiquer un échec, puis concevoir un workflow qu'un autre développeur peut reprendre. On y apprend aussi à justifier les cas où un script ou un workflow plus simple suffit. > [!TIP] Indépendant des modèles > Les outils changent vite. Le programme enseigne ce qui reste : écrire un contexte, borner une délégation, vérifier une preuve. Les outils servent d'exemples, pas de sujet. ### La sécurité, au-delà de la conformité Les séances cinq et six sont consacrées à la sécurité. Le message est explicite : une démarche de conformité ne suffit plus quand des attaquants s'outillent eux aussi d'agents. On y distingue ce qui est déjà observé, ce qui est démontré en laboratoire et ce qui reste prospectif, pour que l'équipe se prépare sans céder à l'alarmisme. ### Un parcours pour les dirigeants L'adoption ne se joue pas seulement dans le code. Un parcours dédié aborde la responsabilité, le changement d'organisation et la mesure de l'usage ; les dirigeants qui suivent les séances techniques sont évalués sur les mêmes critères que les développeurs. ## Ce que montrent les preuves Les supports existent et se consultent : présentations, notes orales, supports PDF et sujets d'exercices, tirés d'un socle d'unités dont chacune est reliée à des critères d'évaluation[^core]. L'outil qui les présente a lui-même été construit avec des agents, selon la méthode enseignée[^tool]. ## Ce que cela change Pour l'équipe, l'enjeu est de remplacer des usages isolés par une base commune, que l'on peut relire et améliorer. Les développeurs apprennent à justifier quand un agent est utile, et à le prouver ; la direction obtient un vocabulaire et des critères pour suivre l'adoption. L'orientation du programme a été acceptée le 9 octobre 2026[^schedule], et la première séance a lieu le vendredi 16 octobre 2026. Je compléterai ce dossier avec les retours des participants et les premiers résultats d'évaluation. ## Limites - Ce dossier décrit un programme conçu et prêt à être animé, pas encore une formation délivrée. - Les critères d'évaluation sont définis ; aucun résultat d'apprentissage n'est mesuré. - La taille de la cohorte et le temps d'exercice protégé restent à fixer. [^core]: Le socle compte dix-sept unités avec leçons, présentations, notes orales et ateliers ; cette édition en tire huit séances. [^tool]: Un outil d'écriture et de présentation des séances, écrit pour l'occasion avec des agents de code, sous ma relecture. [^schedule]: Huit à dix vendredis après-midi avaient été négociés ; l'édition retenue compte huit séances. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/formation-ingenierie-agentique *** --- title: "Zedflow, des flux d’agents lisibles, composables et contrôlés" description: "Mon moteur de flux d’agents : chaque flux est un graphe typé, validé avant exécution, avec des validations humaines sur des données typées et une trace de chaque tour." url: "https://mc-stud.io/realisations/zedflow-flux-agents" author: "Matisse Chenavas" date: "2026-10-09" lang: "fr" ai: "true" --- # Zedflow, des flux d’agents lisibles, composables et contrôlés > Avec Zedflow, un flux d’agents se lit, se valide et se compose comme un programme, et les décisions sensibles attendent une validation humaine. - **Client**: MC Studio, recherche et développement - **Secteur**: Outillage d’agents IA - **Période**: 2026 - **Mon rôle**: Concepteur et unique développeur - **Cadre**: Projet interne - **Équipe**: Seul · 1 personne - **Statut**: Pilote - **Technologies**: Rust, TypeScript, Vue.js, ADK-Rust - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Pour confier à des agents des tâches qui engagent l’entreprise, il faut pouvoir lire, contrôler et relire ce qu’ils font. - **Mécanisme** : Un graphe strict, validé avant exécution, où une stratégie de contexte compose ce que chaque modèle reçoit et où chaque tour est tracé. - **Preuve** : Le moteur, son studio web et l’outil en ligne de commande zf, publiés sur GitHub et utilisés pour préparer ma facturation mensuelle. - **Impact** : Un agent devient auditable : on sait ce qu’il a vu, ce qu’il a fait et où un humain a tranché. - **Limites** : Zedflow est en préversion et sans utilisateur externe ; une partie de l’exécution est conçue mais pas encore implémentée. ## Le point de départ Les agents IA savent enchaîner des actions. Ce qui manque le plus souvent, c'est la possibilité de lire ce qu'ils vont faire avant de les lancer, de contrôler ce qu'ils voient, et de retrouver après coup pourquoi ils ont agi ainsi. Sans cela, il est difficile de leur confier autre chose que des tâches sans conséquence. ## Ce que j'ai construit Zedflow est un moteur et un studio de flux d'agents[^adk]. Un flux est un graphe typé, vérifié avant de s'exécuter : une transition invalide ou une donnée mal déclarée est refusée avec un diagnostic précis, au lieu d'échouer au milieu d'une exécution. À chaque tour, une stratégie de contexte décide, bloc par bloc, de ce que le modèle reçoit ; l'état vit dans des magasins typés, pas dans le prompt. Des passerelles relient les flux entre eux, chacun avec sa responsabilité, son contexte et ses outils. Les validations humaines sont des étapes du graphe, vérifiées sur des données typées : un agent peut préparer une facture, il ne peut pas l'envoyer tant que la personne responsable n'a pas validé. > [!NOTE] Une usine logicielle, pas un agent unique > L'idée directrice : un flux spécialisé par responsabilité, composé avec les autres comme une chaîne de production, avec des humains qui approuvent ce qui compte. ## Ce que montrent les preuves Le code est public, avec le moteur, le studio web et l'outil en ligne de commande[^git]. On peut l'essayer en local avec un fournisseur de démonstration, sans compte ni modèle réel. Chaque tour se relit dans le studio : ce que le modèle a reçu, les outils appelés, ce qui a changé. ## Ce que cela change Pour un client, cette approche rend un agent auditable, et c'est la condition pour lui confier des tâches qui engagent l'entreprise. Je l'applique d'abord à moi-même : Zedflow prépare ma facturation mensuelle, et rien n'en sort sans mon accord[^billing]. C'est aussi un terrain d'essai pour ce que je recommande à mes clients : des agents utiles, bornés, et dont chaque décision se relit. ## Limites - Les formats et les interfaces évoluent encore, et une partie de l'exécution est conçue mais pas encore implémentée. - Aucun utilisateur externe à ce jour ; le seul usage réel est interne à MC Studio. - La licence, PolyForm Noncommercial 1.0.0, réserve l'usage commercial à un accord séparé. [^adk]: Zedflow s'appuie sur ADK-Rust, dont les workflows en graphe suivent les mêmes principes que LangGraph. [^git]: 690 commits, tous de ma main, du 8 juillet 2026 au 3 octobre 2026 (branche principale du dépôt public, relevé le 12 octobre 2026). [^billing]: Des agents préparent les brouillons de facture et d'email ; l'envoi attend ma validation explicite, une étape du graphe. ## Liens - [Dépôt GitHub](https://github.com/ZEDIUM-Off/zedflow) --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/zedflow-flux-agents *** --- title: "Choisir un moteur de lecture de cartes santé sur des preuves, pas sur une démo" description: "Pour Santécie, un banc d’essai qui compare des moteurs OCR et VLM pour lire des cartes de complémentaire santé, sous contraintes de données de santé, avec une vérification humaine de chaque champ." url: "https://mc-stud.io/realisations/scie-ocr-cartes-complementaire-sante" author: "Matisse Chenavas" date: "2026-10-05" lang: "fr" ai: "true" --- # Choisir un moteur de lecture de cartes santé sur des preuves, pas sur une démo > Le choix d’un moteur de lecture des cartes de complémentaire santé repose sur un banc d’essai reproductible, pas sur une démonstration commerciale. - **Client**: Santécie - **Secteur**: Santé, complémentaire santé - **Période**: 2026 - **Mon rôle**: Responsable du projet et architecte - **Cadre**: Via un partenaire - **Équipe**: Seul · 1 personne - **Statut**: Démonstrateur - **Technologies**: Python, NestJS, Docker, TypeScript, Marimo, OCR, VLM - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Avant de choisir un moteur de lecture des cartes santé, Santécie devait savoir lequel est fiable, et où les données ont le droit d’aller. - **Mécanisme** : Un noyau commun pilote en NestJS des pipelines Python versionnés, dont chaque exécution produit des artefacts immuables, donc comparables. - **Preuve** : Onze décisions d’architecture, une analyse des offres OCR sous contrainte HDS et 206 tests automatisés, dans un dépôt dont je suis le seul auteur. - **Impact** : Santécie peut trancher entre traitement local, modèle open-weight hébergé et service externe sur des mesures, avant d’engager un fournisseur. - **Limites** : C’est un démonstrateur : aucun taux de reconnaissance n’est publié, et il ne revendique ni qualité de production ni conformité médicale. ## Indicateurs - 11 décisions d’architecture consignées - 206 tests automatisés qui passent en local ## Le point de départ Lire une carte de complémentaire santé paraît simple. En pratique, les formats varient d'un organisme à l'autre, les photos sont prises dans des conditions imparfaites, et surtout les données relèvent de la santé : où elles sont traitées, par qui et pour combien de temps n'est pas un détail d'implémentation[^hds]. La tentation, sur ce type de sujet, est de brancher le service le plus en vue et de juger sur quelques exemples. Le parti pris du projet est inverse : construire d'abord de quoi comparer, puis choisir. ## Ce que j'ai construit La cible est un outil qui lit la carte sur le poste et propose des champs métier, chacun facultatif et modifiable, qu'une personne vérifie avant toute confirmation. Pour choisir le moteur qui le rendra possible, j'ai d'abord construit le banc d'essai. Chaque pipeline y est versionné et produit des artefacts qui ne changent plus : on compare deux moteurs, ou deux réglages, sans ambiguïté. J'ai séparé le pilotage (NestJS) de l'exécution (Python) et isolé l'inférence des workers, pour changer de modèle sans toucher au reste. Un outil d'annotation construit la vérité de référence, champ par champ, sur des cartes spécimens. > [!TIP] Construire de quoi comparer avant de choisir > Un banc d'essai paraît lent au départ. En réalité, il accélère tout le reste : chaque nouvelle option se teste en quelques heures, et la discussion porte sur des résultats, pas sur des démonstrations. ## Ce que montrent les preuves Une part importante du travail est écrite : les décisions d'architecture, une analyse des fournisseurs OCR hébergés et de leurs engagements de confidentialité, des notes sur l'inférence de modèles open-weight. Elles permettent au client de comprendre pourquoi une option est retenue ou écartée, et à un nouveau développeur de reprendre le projet sans tout redécouvrir[^git]. Le code est vérifié par une suite de tests automatisés[^tests]. Les comparaisons se lisent dans des carnets, à partir des artefacts immuables de chaque campagne. ## Ce que cela change La question « faut-il sortir les données du poste ? » se tranche sur des mesures, pas sur une promesse commerciale. La cible du prochain banc d'essai, sur une infrastructure GPU dédiée, est décidée ; ses résultats alimenteront le choix entre traitement local, modèle open-weight hébergé et service externe, avec une rétention nulle si une API externe est retenue pour le banc. ## Limites - Aucun taux de reconnaissance n'est publié : les résultats du banc d'essai sur infrastructure dédiée ne sont pas encore disponibles. - Les captures montrent l'outil d'annotation et un carnet de comparaison sur des données synthétiques, pas un produit fini. - Les échantillons réels restent privés et ne sortent pas du cadre du client. - Le système ne vérifie pas les droits et ne prend aucune décision automatisée. [^hds]: HDS, pour hébergement de données de santé : la certification exigée en France pour héberger des données de santé pour le compte d'un tiers. Elle a guidé l'analyse des offres OCR hébergées. [^git]: Seul auteur du dépôt : 207 commits, du 14 août au 5 octobre 2026. [^tests]: 206 tests passent en local au 7 octobre 2026. Ils vérifient le code, pas la qualité de lecture. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/scie-ocr-cartes-complementaire-sante *** --- title: "Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande" description: "Pour Santécie, distributeur de dispositifs médicaux, une automatisation en production qui transforme les fiches de retour SAV en formulaires fabricants remplis, avec une trace d’audit pour chaque demande." url: "https://mc-stud.io/realisations/robotform-formulaires-sav" author: "Matisse Chenavas" date: "2026-09-18" lang: "fr" ai: "true" --- # Automatiser les retours SAV vers les fabricants, avec une trace de chaque demande > Les fiches de retour SAV de Santécie sont routées vers les bons formulaires fabricants et remplies automatiquement, avec une trace d’audit pour chaque demande. - **Client**: Santécie - **Secteur**: Santé, distribution de dispositifs médicaux - **Période**: 2024-2026 - **Mon rôle**: Développeur principal, back-end et front-end - **Cadre**: Via un partenaire - **Équipe**: Intégré à une équipe existante · 2 personnes (Intégré à l’équipe projet, avec un second développeur sur 2024-2025.) - **Statut**: En production - **Technologies**: NestJS, Prisma, Vue.js, Pinia, TypeScript, BullMQ - **Temps de lecture** : 5 min ## L’essentiel - **Enjeu** : Chaque retour SAV doit partir vers le fabricant sur son propre formulaire ; la recopie manuelle prenait du temps et exposait à des erreurs coûteuses. - **Mécanisme** : Des règles de routage versionnées désignent les formulaires cibles, une automatisation déterministe les remplit, et l’IA ne voit que des échantillons synthétiques. - **Preuve** : Des dizaines de milliers de demandes traitées en production depuis septembre 2025, avec 100 % de complétion opérationnelle selon mon suivi d’exploitation. - **Impact** : La saisie devient de la configuration : au moins 500 heures évitées par tranche de 10 000 demandes, et un échec se rejoue isolément. - **Limites** : Les indicateurs viennent du suivi d’exploitation que je déclare ; ils n’ont pas été audités de façon indépendante. ## Indicateurs - des dizaines de milliers de demandes traitées en production depuis septembre 2025 - 100 % de complétion opérationnelle, au sens défini ci-dessus - 0 échec opérationnel, pannes externes suivies à part - ≥ 500 h de saisie évitées par tranche de 10 000 demandes (estimation) ## Le point de départ Santécie distribue des dispositifs médicaux. Quand un appareil revient en SAV, le retour doit partir vers le fabricant avec le bon formulaire, rempli selon son modèle à lui : chaque fabricant a ses champs, ses versions et ses exigences. Les fiches de retour arrivent le plus souvent sous forme de fichiers Excel, et quelqu'un devait en reporter le contenu, formulaire après formulaire. Ce travail n'exige aucun jugement, mais une attention constante, et une erreur de report coûte cher à corriger. La demande était donc double : supprimer la recopie, et savoir après coup ce qui a été envoyé, où et pourquoi. ## Ce que j'ai construit Le cœur du système n'est pas le remplissage, mais le **routage**. Une fiche peut concerner un formulaire, plusieurs, ou aucun selon son contenu. J'ai structuré le domaine autour de trois notions nettes : le groupe de formulaires, identifié par un code métier stable ; la configuration de routage, écrite comme une suite de conditions ; la cible de remplissage, qui associe un formulaire à une version précise. Deux décisions ont pesé. Le routage se résout au moment de l'exécution, puis se fige avec elle : on corrige une règle sans réécrire l'histoire, et chaque formulaire rempli garde la règle qui l'a produit. J'ai aussi distingué, avec l'équipe, la complétion d'une demande, qui relance seulement ce qui a échoué, de son rejeu complet. Une API NestJS avec Prisma porte le domaine, des files BullMQ absorbent les volumes, et une interface Vue 3 sert à gérer les formulaires, leurs versions et les règles. L'accès est réparti par rôle, opérateur ou administrateur, et les journaux comme les contenus traités ont une durée de conservation. ### Où passe l'IA, et où elle ne passe pas Sur des données de santé, la question n'est pas de savoir si l'IA peut aider, mais où elle a le droit d'intervenir. Les demandes de production passent par une automatisation déterministe, avec des règles et un schéma stricts. L'analyse assistée par IA sert uniquement, sur des échantillons synthétiques, à générer les modèles de correspondance entre les colonnes reçues et les champs d'un formulaire. La validation humaine porte en amont, sur la configuration, et non sur chaque demande. > [!IMPORTANT] La frontière de données > Les contenus de production ne passent jamais par un modèle de langage. L'IA accélère la préparation des correspondances ; elle ne voit pas les fiches réelles. ## Travailler dans l'équipe, pas à côté J'ai rejoint ce projet comme on rejoint une équipe : par son code, son vocabulaire et ses habitudes, et j'en suis devenu l'auteur principal[^git]. Le dépôt porte aujourd'hui ce qui permet à quelqu'un d'autre, humain ou agent, de le reprendre : un fichier de contexte à la racine, des décisions d'architecture consignées une par une, un audit des flux et un glossaire métier partagé avec les utilisateurs. Ce glossaire a compté plus qu'il n'y paraît. Une « demande » n'est pas un « lot », un « rejeu » n'est pas une « complétion ». Le jour où un utilisateur demande pourquoi un formulaire a été rempli deux fois, la réponse tient dans ces distinctions. ## Ce que montrent les preuves L'automatisation tourne en production depuis septembre 2025. Les chiffres ci-dessous viennent de mon suivi d'exploitation[^volume], et ils ne se lisent qu'avec leur définition. > [!NOTE] Définition de la complétion opérationnelle > L'automatisation remplit le formulaire de bout en bout, sans reprise manuelle, et produit une trace d'audit de l'exécution. Ce taux ne dit rien de la justesse sémantique d'une correspondance. Les pannes de dépendances externes sont suivies à part, comme incidents. La trace, elle, se consulte à tout moment : pour une demande donnée, l'outil montre quelle règle s'est appliquée, quelle branche a été retenue et quelles conditions ont été évaluées. ## Ce que cela change La ressaisie se déplace vers la configuration : une règle se paramètre une fois et s'applique à chaque fiche reçue. À raison de 3 à 5 minutes de saisie manuelle par formulaire, chaque tranche de 10 000 demandes représente entre 500 et 830 heures de saisie évitées[^estimate]. Quand une fiche échoue, on sait quelle règle l'a dirigée où, et on la complète ou on la rejoue sans reprendre le lot entier. Le système continue d'évoluer, avec des travaux récents sur l'intégration au routage SAP et sur le déploiement. J'y travaille en indépendant, intégré à l'équipe projet : d'abord en micro-entreprise, puis via MC Studio depuis janvier 2026. ## Limites - Les comptages sont les miens : ils n'ont pas fait l'objet d'un audit indépendant, et le volume exact se communique sur demande. - Le taux de complétion mesure l'exécution de bout en bout avec sa trace, pas la justesse de chaque correspondance. - Le temps évité est une estimation fondée sur une durée de saisie manuelle, pas une mesure avant et après. - Le projet est mené en équipe : les choix de produit ont été partagés, et je n'en revendique pas seul la direction. [^git]: Historique Git du dépôt : 113 des 193 commits sont les miens, de juillet 2024 à septembre 2026. Un second développeur a contribué en 2024 et 2025. Un nombre de commits ne mesure ni l'effort ni la qualité. [^volume]: Comptages agrégés issus du suivi d'exploitation, que je déclare. Le volume exact et un export anonymisé des comptages se communiquent sur demande. [^estimate]: 10 000 demandes × 3 minutes = 500 heures ; × 5 minutes = environ 830 heures. La durée de 3 à 5 minutes est une estimation du remplissage manuel, pas une mesure. ## Liens - [Santécie](https://santecie.com/) --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/robotform-formulaires-sav *** --- title: "Faire d’une méthode d’entraînement une application mobile et son back-office" description: "Pour Essan NFC, une application Expo / React Native et un back-office MedusaJS qui couvrent la planification des séances, le coaching, la nutrition et les abonnements, avec un coach IA cadré par la méthode." url: "https://mc-stud.io/realisations/nfc-training-application-mobile" author: "Matisse Chenavas" date: "2026-08-10" lang: "fr" ai: "true" --- # Faire d’une méthode d’entraînement une application mobile et son back-office > La méthode NFC existe sous forme de produit : une application mobile pour les pratiquants et un back-office pour l’équipe, sur un socle commun. - **Client**: Essan NFC - **Secteur**: Sport et coaching - **Période**: 2025-2026 - **Mon rôle**: Développeur principal, mobile, back-office et IA - **Cadre**: Via un partenaire - **Équipe**: Intégré à une équipe existante · 4 personnes (Intégré à l’équipe projet, avec au moins trois autres développeurs.) - **Statut**: En pause - **Technologies**: Expo, React, Node.js, Medusa, PostgreSQL, TypeScript, pgvector, pnpm - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : La méthode d’Essan NFC vivait dans des documents et des échanges individuels, et dépendait donc de la disponibilité des personnes qui la portent. - **Mécanisme** : Une application Expo / React Native et un back-office MedusaJS partagent un monorepo ; le coach IA lit le contexte du pratiquant sans le modifier. - **Preuve** : Principal contributeur du dépôt de septembre 2025 à août 2026, avec une chaîne de build iOS validée sur un iPhone réel. - **Impact** : La méthode devient un parcours que l’équipe administre, et le coach répond à partir des données du pratiquant plutôt que de généralités. - **Limites** : Le projet est en pause : publication sur les stores, nombre d’utilisateurs et résultats commerciaux restent inconnus. ## Le point de départ Essan NFC dispose d'une méthode d'entraînement : des séances, une progression, un suivi nutritionnel, un accompagnement par des coachs. Tant que cette méthode vit dans des documents et des échanges individuels, elle ne peut pas suivre beaucoup de pratiquants à la fois. Le projet consistait à la numériser sans l'appauvrir. ## Ce que j'ai construit J'ai été le principal développeur de l'application et de son back-office, intégré à l'équipe projet. Le périmètre MVP couvre la planification des séances, la nutrition, le coaching, les abonnements et le profil. Le back-office, construit sur MedusaJS, donne à l'équipe d'Essan la main sur les contenus, les utilisateurs et les coachs ; PostgreSQL et pgvector portent les données. ### Un coach IA qui ne répond pas de mémoire Le coach IA a demandé le plus de soin. Un assistant conversationnel branché sans cadre produit vite des conseils génériques, voire hasardeux, sur un sujet qui touche à la santé. Ici, le modèle reçoit le contexte du pratiquant au moyen de commandes en lecture seule et procède par cycles de recherche bornés : il s'appuie sur ce qui est connu, et ne peut rien modifier. Le projet a aussi exploré l'exécution d'un modèle compact directement sur le téléphone, pour la confidentialité et le fonctionnement hors ligne[^ondevice]. Cette piste est restée une expérimentation de développement. > [!NOTE] Exploration n'est pas engagement > Tester un modèle sur l'appareil a servi à apprendre ce qui pourrait changer une décision : taille, rapidité, qualité. Le produit, lui, est resté sur un modèle hébergé. ## Ce que montrent les preuves L'historique du dépôt montre ma part du travail[^git], et la documentation du coach IA décrit ses commandes et ses limites. Pour tester sur un iPhone réel sans dépendre d'un service de build en ligne, j'ai mis en place une chaîne qui compile et signe l'application sur un Mac, puis l'installe sur l'appareil[^ios]. ## Ce que cela change La méthode n'est plus portée seulement par des documents et des échanges : elle devient un parcours structuré que l'équipe administre. Le coach IA est conçu pour s'appuyer sur les données du pratiquant, et non sur des conseils généraux. ## Limites - Le projet est en pause ; je compléterai ce dossier avec son statut de publication et ses premiers usages dès qu'ils seront connus. - En production, le coach IA s'appuie sur un modèle hébergé dans le cloud. L'exécution sur le téléphone n'a été qu'une expérimentation. - Les programmes et conseils nutritionnels restent informatifs et ne remplacent pas un avis médical. - Les captures sont un rendu web de l'application mobile, sur un compte de test : la barre d'onglets n'y a pas exactement son rendu natif. [^ondevice]: Un modèle Gemma au format GGUF, chargé avec @react-native-ai/llama, accessible seulement depuis un panneau de débogage réservé au développement. [^git]: Historique Git : 222 des 340 commits sont les miens, de septembre 2025 à août 2026, aux côtés d'au moins trois autres développeurs. Un nombre de commits ne mesure ni l'effort ni la qualité. [^ios]: Chaîne validée le 24 juillet 2026 : compilation et signature sur un Mac distant, installation sur un iPhone physique. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/nfc-training-application-mobile *** --- title: "Un environnement de développement maîtrisé, prêt pour coder avec l’IA" description: "Pour Silico, un registre privé d’environnements de développement décrits en code, et un cadre d’usage de l’IA pour les développeurs : outils autorisés, points de validation, indicateurs définis avant toute mesure." url: "https://mc-stud.io/realisations/environnements-de-developpement-coder" author: "Matisse Chenavas" date: "2026-04-08" lang: "fr" ai: "true" --- # Un environnement de développement maîtrisé, prêt pour coder avec l’IA > Les développeurs de Silico disposent d’environnements standardisés, décrits en code et hébergés sur une infrastructure maîtrisée, socle d’un usage encadré de l’IA. - **Client**: Silico - **Secteur**: Services numériques (ESN) - **Période**: 2026 - **Mon rôle**: Concepteur du registre, contributeur au cadre d’usage de l’IA - **Cadre**: En direct - **Équipe**: Seul · 1 personne - **Technologies**: Coder, Docker, Git, Terraform, Devcontainers - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Avant d’ouvrir le code aux assistants IA, une ESN doit savoir où ils tournent, à quels dépôts ils accèdent et quelle trace ils laissent. - **Mécanisme** : Des modèles Coder s’appuient sur des modules Terraform réutilisables, et des règles de conception écrites fixent comment en ajouter. - **Preuve** : Le registre et sa documentation, que j’ai écrits seul en une semaine début avril 2026. - **Impact** : Un poste ou un projet repart d’une base commune et versionnée, et la question « où l’assistant peut-il travailler ? » reçoit une réponse technique. - **Limites** : L’adoption du registre par les équipes n’est pas mesurée, et aucun gain lié à l’IA n’est revendiqué. ## Le point de départ Dans une équipe qui enchaîne les projets clients, chaque développeur finit par avoir son propre environnement, légèrement différent de celui de ses collègues. Les écarts restent invisibles jusqu'au jour où ils coûtent une demi-journée de diagnostic. Quand des assistants IA entrent dans le travail quotidien, la question devient plus sérieuse : sur quelle machine l'assistant tourne-t-il, à quels dépôts accède-t-il, et que reste-t-il comme trace ? Une règle écrite ne suffit pas si l'environnement ne la porte pas. ## Ce que j'ai construit J'ai conçu un registre privé de modèles pour Coder, l'outil qui crée les environnements de travail des développeurs. Chaque modèle, devcontainer ou envbuilder, s'appuie sur des modules Terraform réutilisables : la base de données du projet, l'environnement applicatif, la gestion des sous-modules Git. Des règles de conception écrites expliquent comment ajouter un modèle sans dupliquer ce qui existe. Le choix structurant a été de décrire les environnements en code. Un environnement devient un artefact versionné, relu et reproductible ; le corriger une fois le corrige pour tout le monde. ### Un cadre pour coder avec l'IA Sur ce socle, j'ai contribué à définir des pratiques d'usage maîtrisé de l'IA pour le développement[^iso] : quels outils sont autorisés, quels dépôts demandent une validation supplémentaire avant fusion, comment évaluer un assistant sur des tâches réelles, une fonctionnalité, une correction, une refonte, avant de l'adopter. ## Ce que montrent les preuves Le registre et ses règles de conception sont la preuve directe de ce travail[^git]. Pour le cadre d'usage de l'IA, la preuve est d'une autre nature : des indicateurs définis avec leur méthode, prêts à être relevés[^baseline]. > [!NOTE] Des indicateurs définis avant d'être mesurés > Débit de revues de code, taux de défauts après fusion, couverture de tests, coût de revue : chaque indicateur a sa méthode de mesure et une valeur de référence à relever avant le déploiement. Je ne revendique aucun gain tant que cette mesure n'existe pas. ## Ce que cela change Un nouveau poste ou un nouveau projet repart d'une base commune et versionnée ; les écarts entre environnements se réduisent par construction. Pour l'adoption de l'IA, l'environnement où l'assistant travaille devient un objet que l'on peut relire et contrôler. J'en retiens que la sécurité d'un usage de l'IA dans le code se décide en amont, dans cet environnement. C'est un chantier court, mais il conditionne la suite : la confiance des développeurs, celle de la direction, et la possibilité de mesurer. ## Limites - Le nombre de développeurs et de projets qui utilisent le registre n'est pas mesuré à ce jour. - Les indicateurs du cadre sont définis mais pas encore mesurés : aucun gain avant et après n'est revendiqué. - Le cadre s'inscrit dans une démarche d'alignement sur l'ISO/IEC 27001 ; il ne constitue pas une certification. [^iso]: Dans le cadre de la démarche de gouvernance de Silico, alignée sur l'ISO/IEC 27001. Le registre lui-même ne contient aucun élément propre à la norme. [^git]: Seul auteur du registre : 18 commits, du 1er au 8 avril 2026. [^baseline]: Les valeurs de référence se relèvent pendant une phase de découverte, et les cibles se fixent avec les responsables techniques et sécurité. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/environnements-de-developpement-coder *** --- title: "Relier les mâts LumiSafe à une passerelle logicielle, pour la sécurité des voies ferrées" description: "Pour Cesatec, une passerelle Python et le firmware des mâts LumiSafe, un système breveté de sécurité pour la maintenance ferroviaire, reliés par un protocole série conçu pour rester compatible d’une version à l’autre." url: "https://mc-stud.io/realisations/lumisafe-signalisation-mats" author: "Matisse Chenavas" date: "2026-04-08" lang: "fr" --- # Relier les mâts LumiSafe à une passerelle logicielle, pour la sécurité des voies ferrées > Les mâts LumiSafe dialoguent avec une passerelle logicielle par un protocole série qui évolue sans casser les mâts restés sur une version antérieure. - **Client**: Cesatec - **Secteur**: Sécurité ferroviaire, maintenance des voies - **Période**: 2026 - **Mon rôle**: Concepteur et unique développeur de la passerelle et du firmware - **Cadre**: Via un partenaire - **Équipe**: Seul · 1 personne - **Technologies**: Python, Arduino, UART - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Sur une voie en maintenance, chacun doit savoir en temps réel si un agent la protège, chef d’équipe compris, même à distance. - **Mécanisme** : Une passerelle Python, Hermes, échange avec le firmware Arduino des mâts par UART ; le protocole porte un mode verrouillé et l’affectation à une équipe. - **Preuve** : Le code et la documentation de la passerelle et du firmware, que j’ai écrits seul entre février et avril 2026. - **Impact** : L’état de chaque mât devient lisible par logiciel, au service de la supervision à distance, et le protocole s’enrichit sans tout mettre à jour. - **Limites** : Le déploiement sur le terrain et ses résultats ne sont pas documentés ici : ce dossier décrit le logiciel, pas son exploitation. ## Le point de départ LumiSafe est un système breveté de Cesatec pour la sécurité des agents de maintenance ferroviaire[^product]. Sur la voie, des mâts lumineux reçoivent le badge des agents, qui signalent ainsi leur présence. Le code couleur se lit de loin : vert, la voie n'est pas protégée ; orange, une protection est demandée, de type 1, 2 ou 3 ; rouge, la voie est protégée par un agent. Les chefs d'équipe suivent ces états à distance, en temps réel. Pour que cette information circule, chaque mât doit parler à un logiciel de façon fiable, et ce dialogue doit pouvoir évoluer sans immobiliser le matériel déjà installé. ## Ce que j'ai construit J'ai développé les deux extrémités de la chaîne : Hermes, une passerelle en Python, et le firmware Arduino des mâts, reliés par un protocole série sur UART. Le protocole porte un mode verrouillé, les champs d'affectation d'un mât à une équipe, et une variante de mât équipée d'un écran OLED. Une règle guide tout le reste : faire évoluer le protocole sans casser la compatibilité avec les versions précédentes[^compat]. Un mât qui n'a pas été mis à jour doit continuer de fonctionner avec une passerelle plus récente. > [!TIP] Un protocole matériel se conçoit comme une API publique > Une fois des appareils en service, on ne les met pas tous à jour le même jour. Ajouter des champs sans changer le sens des anciens coûte un peu de discipline, et évite d'avoir à synchroniser tout un parc. ## Ce que montrent les preuves Le travail tient dans deux dépôts, la passerelle et le firmware, avec leur documentation et leurs règles de projet[^git]. Il n'y a pas de capture : ce travail n'a pas d'interface à montrer, seulement un protocole et deux programmes qui le parlent. ## Ce que cela change L'état de chaque mât, la présence d'un agent, la protection demandée ou accordée, devient une donnée que le logiciel peut lire et transmettre, ce qui rend possible le suivi à distance par les chefs d'équipe. Le protocole peut s'enrichir sans imposer la mise à jour simultanée de tous les mâts. ## Limites - Je n'ai conçu ni le système LumiSafe ni son brevet : mon périmètre est la passerelle et le firmware. - Aucun indicateur de terrain n'est disponible : nombre de mâts, chantiers, incidents évités. - Ce dossier ne publie ni le protocole ni le code, qui appartiennent au cadre de la mission. [^product]: Description du produit d'après la page LumiSafe du site de Cesatec, liée dans la fiche du projet. [^compat]: Règle de projet écrite dans les dépôts : privilégier des changements de protocole rétrocompatibles. [^git]: Seul auteur des deux dépôts : 11 commits sur la passerelle, de février à avril 2026, et 3 sur le firmware, en février 2026. ## Liens - [LumiSafe, sur le site de Cesatec](https://cesatec.fr/marques/lumisafe/) --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/lumisafe-signalisation-mats *** --- title: "Une mémoire partagée entre agents, cloisonnée par rôle" description: "Sur un fork du projet open source OpenClaw, une mémoire en graphe pour agents, hébergée sur Memgraph, où chaque agent ne lit et n’écrit que dans son propre périmètre." url: "https://mc-stud.io/realisations/memoire-agents-cloisonnee" author: "Matisse Chenavas" date: "2026-02-08" lang: "fr" ai: "true" --- # Une mémoire partagée entre agents, cloisonnée par rôle > Plusieurs agents s’appuient sur une mémoire en graphe commune, sans qu’aucun n’accède au périmètre d’un autre. - **Client**: MC Studio, recherche et développement - **Secteur**: Agents IA, gestion des connaissances - **Période**: 2026 - **Mon rôle**: Concepteur et unique développeur de la fonctionnalité - **Cadre**: Projet interne - **Équipe**: Seul · 1 personne - **Statut**: Démonstrateur - **Technologies**: TypeScript, Docker, Memgraph, Cypher, Vitest - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Des agents qui partagent une mémoire ne doivent pas lire le périmètre des autres ; une consigne dans le prompt ne suffit pas. - **Mécanisme** : L’application vérifie le périmètre de chaque acteur avant toute requête Cypher, et la base Memgraph applique des rôles distincts dès l’initialisation. - **Preuve** : Le code public de la branche session-ux : règles d’accès, tests unitaires et tests de bout en bout contre une vraie base Memgraph. - **Impact** : Une connaissance partagée qui ne fuit pas d’un périmètre à l’autre : la condition de départ pour des agents qui se souviennent. - **Limites** : Le cloisonnement est fait par agent ; les périmètres par client et les tests offensifs restent à réaliser. ## Le point de départ Dès que plusieurs agents travaillent ensemble, ils ont besoin de mémoire : ce qui a été décidé, ce qui a été appris, ce qui reste à faire. Une mémoire commune pose aussitôt une autre question. Si un agent travaille pour une personne, une équipe ou un client, il ne doit pas pouvoir lire ce que les autres ont confié aux leurs. Demander au modèle de « ne pas regarder » ne suffit pas. ## Ce que j'ai construit Sur un fork d'OpenClaw, un projet open source d'agents[^fork], j'ai ajouté une mémoire en graphe hébergée sur Memgraph, lancé en conteneur. Chaque acteur reçoit un périmètre : un agent lit et écrit dans le sien, l'opérateur dispose d'un périmètre d'administration. Avant chaque requête, l'application vérifie que le périmètre demandé est bien celui de l'acteur, et refuse sinon. La base de données applique la même logique de son côté : des rôles distincts pour l'administration, les agents et les équipes, créés dès l'initialisation avec leurs propres utilisateurs. Si une requête passait le premier contrôle par erreur, elle se heurterait au second. Agents et administrateurs disposent chacun d'une skill qui décrit l'usage de la mémoire. > [!IMPORTANT] L'isolation ne se délègue pas au prompt > Un modèle peut être convaincu d'ignorer une consigne. Une règle d'accès dans le code et dans la base, elle, ne se négocie pas. ## Ce que montrent les preuves Les règles d'accès sont couvertes par des tests unitaires : un agent accède à son périmètre et se voit refuser celui d'un autre. Des tests de bout en bout tournent contre une vraie base Memgraph, pour vérifier que l'ensemble tient hors des maquettes[^tests]. Le code est public et se relit sur la branche[^deck]. ## Ce que cela change Pour une organisation qui veut des agents capables de se souvenir, c'est la condition de départ : une connaissance partagée qui ne fuit pas d'un périmètre à l'autre. La même logique, étendue aux clients ou aux missions, éviterait qu'un agent mobilise dans un dossier ce qu'il a appris dans un autre. C'est la direction que je propose quand une organisation veut des agents qui se souviennent, sans mélanger les dossiers. ## Limites C'est un démonstrateur personnel : il établit le mécanisme, sans utilisateur externe, et je n'en revendique que ce que le code montre. - L'extension à des périmètres par client ou par mission est une piste, pas une réalisation. - Les tests de sécurité offensifs, injection de prompt et tentatives d'exfiltration entre périmètres, sont prévus mais pas encore réalisés. - C'est une branche de fork, non proposée au projet d'origine. [^fork]: OpenClaw est un projet open source tiers. Seule la fonctionnalité de mémoire cloisonnée de cette branche est de moi, développée seul en février 2026. [^tests]: Tests unitaires Vitest sur les règles d'accès ; tests de bout en bout lancés par un script et une configuration dédiés, contre Memgraph en conteneur. [^deck]: Ma présentation de ce travail évoque aussi des journaux d'audit et des réponses qui citent leurs sources. Je ne les ai pas encore vérifiés dans la branche, donc je ne les revendique pas ici. ## Liens - [Branche session-ux du fork](https://github.com/ZEDIUM-Off/openclaw/tree/session-ux) --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/memoire-agents-cloisonnee *** --- title: "Une application de demandes de congés payés pour CICP2R" description: "Pour CICP2R, caisse de congés payés, une application web où les demandes de congés payés et les jours à payer sont saisis côté employeur, puis validés et transmis." url: "https://mc-stud.io/realisations/cicp-demandes-de-conges" author: "Matisse Chenavas" date: "2025-11-19" lang: "fr" --- # Une application de demandes de congés payés pour CICP2R > Côté employeur, les demandes de congés payés et les jours à payer se saisissent dans une application dédiée, puis passent par une validation explicite. - **Client**: CICP2R - **Secteur**: Protection sociale, caisse de congés payés - **Période**: 2024-2025 - **Mon rôle**: Développeur full-stack, contributeur - **Cadre**: Via un partenaire - **Équipe**: Intégré à une équipe existante · 5 personnes (Au sein d’une équipe d’au moins cinq développeurs.) - **Technologies**: NestJS, Vue.js, Pinia, TypeScript - **Temps de lecture** : 3 min ## L’essentiel - **Enjeu** : Une caisse de congés payés verse les indemnités des salariés : chaque demande doit lui parvenir complète, chiffrée et validée, sans ressaisie. - **Mécanisme** : Une API NestJS structure les périodes de congé et échange des fichiers par SMB avec le système existant ; Vue 3 porte la saisie. - **Preuve** : Un an de contributions à l’API et à l’interface, de novembre 2024 à novembre 2025, et un audit de l’application en octobre 2025. - **Impact** : Chaque demande a un statut et un circuit identifiables, et l’application s’insère dans les échanges de fichiers existants au lieu de les doubler. - **Limites** : J’ai contribué au sein d’une équipe d’au moins cinq développeurs ; je ne revendique ni la direction ni la conception d’ensemble. ## Le point de départ CICP2R est une caisse de congés payés : une association loi 1901 fondée en 1937 par des employeurs, placée sous le contrôle du ministère du Travail, qui verse aux salariés leurs indemnités de congés payés. Pour qu'elle paie juste, chaque demande doit lui arriver avec ses périodes, ses jours à payer et, le cas échéant, la sortie du salarié. La gestion des congés concentre beaucoup de petites frictions : une demande transmise par un canal, validée par un autre, puis reportée à la main. Chaque étape est simple ; leur enchaînement l'est beaucoup moins. ## Ce que j'ai construit J'ai travaillé sur l'API comme sur l'interface, au sein de l'équipe projet. L'application recueille les demandes, structure les périodes de congé et les conserve avec chaque demande, puis les fait passer par une validation avant export. Côté serveur, l'API NestJS échange des fichiers avec le système existant par transfert SMB : l'application s'inscrit dans le circuit déjà en place au lieu d'en créer un second. Côté interface, Vue 3 et Pinia portent la saisie, la grille des demandes et l'état des congés. ## Ce que montrent les preuves Mon travail se lit dans l'historique des deux dépôts, l'API et l'interface, sur un an[^git]. En octobre 2025, un audit de l'application a documenté son fonctionnement réel[^audit] : stockage des périodes, circuit de validation, gestion de l'état côté interface. Les captures ci-dessous viennent d'une instance locale de l'application, alimentée par des données fictives. ## Ce que cela change Chaque demande a un statut et un circuit identifiables, de la saisie à l'export. L'échange de fichiers avec le système existant évite une double saisie entre l'application et la caisse. J'en retiens qu'un outil RH n'est utile que s'il épouse le circuit réel de l'organisation. La technique compte moins que la justesse de ce circuit et la qualité des échanges avec le système qui paie. ## Limites - Ma part est celle d'un contributeur : d'autres développeurs ont écrit une large part de l'interface. - Aucun indicateur d'usage n'est disponible : volume de demandes, nombre d'employeurs, délais. - La cible exacte de l'échange SMB et la date de mise en service restent à confirmer. - Les documents du projet contiennent des données personnelles : rien n'en est repris ici, et les captures sont réalisées sur des données fictives. [^git]: Historique Git : 33 commits sur l'API et 60 sur l'interface, de novembre 2024 à novembre 2025. Un nombre de commits ne mesure ni l'effort ni la qualité. [^audit]: Notes d'audit d'octobre 2025 : stockage des périodes de congé en JSON, circuit de validation, store Pinia dédié aux congés. Elles ne sont pas publiées, car elles citent des données personnelles. ## Liens - [CICP2R](https://www.cicp2r.org/) --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/realisations/cicp-demandes-de-conges *** --- title: "Rejoindre une équipe, puis augmenter sa façon de travailler avec des agents" description: "Comment j’entre dans une équipe existante et j’y installe, à sa mesure, des primitives de travail agentique : contexte écrit, décisions consignées, skills, workflows avec validation humaine, preuve avant confiance." url: "https://mc-stud.io/articles/rejoindre-une-equipe-et-y-installer-des-primitives-agentiques" author: "Matisse Chenavas" date: "2026-10-11" lang: "fr" ai: "true" --- # Rejoindre une équipe, puis augmenter sa façon de travailler avec des agents > Comment j’entre dans une équipe existante et j’y installe, à sa mesure, des primitives de travail agentique : contexte écrit, décisions consignées, skills, workflows avec validation humaine, preuve avant confiance. 5 min de lecture ## L’essentiel - J’entre dans une équipe par ses rituels et son code, pas par mes outils. - Les premières primitives sont des textes : un fichier de contexte, des décisions consignées, un glossaire. Humains et agents lisent la même source. - Une procédure qui revient devient une skill ; une tâche longue devient un graphe avec des validations humaines. - Rien n’est terminé sans preuve : tests, vérifications, relecture. - Ce site a été construit ainsi, par plusieurs agents aux fichiers attribués, et relu par moi avant publication. La plupart de mes missions commencent de la même façon : une équipe existe déjà, avec son code, ses habitudes, ses rituels et ses angles morts. Je n'arrive pas sur un terrain vierge, et c'est tant mieux. Une équipe qui livre a toujours de bonnes raisons de faire ce qu'elle fait, même quand elle ne les a jamais écrites. Mon rôle n'est pas de remplacer cette façon de travailler par la mienne. Il est d'y ajouter, à la mesure de l'équipe, ce que j'appelle des primitives de travail agentique : des pièces simples, que les humains comme les agents savent utiliser, et qui restent quand je pars. Voici comment je m'y prends, avec des exemples tirés de projets réels et de mon propre atelier. ## D'abord, écouter le dépôt Les premières semaines, je lis plus que je n'écris. L'historique Git, les tickets, les conventions implicites, la façon dont une revue se passe, ce qui fait peur à l'équipe quand elle déploie. Je pose beaucoup de questions, souvent naïves, parce que ce sont celles qu'un agent poserait s'il le pouvait. Ce que je comprends, je l'écris. Pas dans un rapport que personne ne lira, mais dans un fichier court à la racine du dépôt, que l'équipe relit comme du code : à quoi sert ce projet, comment il est organisé, ce qu'il ne faut surtout pas casser, où trouver le reste. C'est la première primitive, et la plus rentable. Un nouvel arrivant y gagne une semaine. Un agent y gagne la différence entre une modification plausible et une modification juste. > [!TIP] Un même texte pour les humains et les agents > Si une règle n'est écrite que dans un prompt, seul l'agent la connaît. Si elle n'est que dans la tête d'un développeur, l'agent l'ignore. Écrite dans le dépôt, elle sert aux deux et se corrige en revue. ## Écrire ce que l'équipe sait déjà La deuxième primitive est la décision consignée. Sur le projet d'automatisation SAV auquel je contribue pour Santécie, le dépôt porte aujourd'hui des décisions d'architecture écrites une par une, un audit des flux et un glossaire métier partagé avec les utilisateurs. Sur le banc d'essai de lecture de cartes de complémentaire santé, onze décisions d'architecture expliquent pourquoi chaque option a été retenue ou écartée. Ces documents ne sont pas de la bureaucratie. Ce sont eux qui permettent de répondre, six mois plus tard, à « pourquoi le système fait-il cela ? ». Et ce sont eux qu'un agent lit avant de proposer un changement, au lieu de deviner. Dans mon propre espace de travail, je pousse la logique plus loin : chaque dossier a un fichier d'instructions pour les agents, chaque projet sa fiche, le contexte durable vit dans `docs/` et l'état temporaire dans un dossier à part. Un agent sait où il est, ce qui s'applique ici, et où écrire ce qu'il découvre. Je ne l'impose pas tel quel à une équipe ; j'en installe la version qui lui sert. ## Transformer les procédures en skills Toute équipe a des procédures qui reviennent : préparer une mise en production, relire une migration, rédiger un compte rendu. Quand une procédure revient assez souvent et qu'elle a des règles de vérification claires, elle devient une skill : un savoir-faire écrit que l'agent charge au bon moment, avec ses étapes et ses contrôles. Chez moi, la préparation de mon compte rendu d'activité mensuel en est une. L'agent reconstitue l'activité à partir de l'historique Git et de mes sessions de travail, sépare les projets, vérifie la couverture de chaque jour, puis prépare la facture et l'email. Il ne les envoie jamais : il me les présente. La bonne skill n'est pas la plus ambitieuse. C'est celle qui retire à l'équipe une tâche qu'elle fait sans plaisir, tout en gardant les points où son jugement compte. ## Passer des conversations aux workflows Une conversation avec un agent suffit pour une tâche courte. Pour une tâche longue, elle devient fragile : le contexte s'épuise, une étape est oubliée, personne ne sait où l'on en est. Je décris alors le travail comme un graphe d'étapes, avec un état explicite, des reprises possibles et des validations humaines aux endroits qui engagent. C'est l'objet de deux outils que je publie, pi-graph et Zedflow. Dans Zedflow, une validation humaine est une étape du graphe, vérifiée sur des données typées : le montant, le destinataire, la période. Pas sur un « ça a l'air bon ». ## La preuve avant la confiance Un agent qui annonce « c'est fait » n'a rien prouvé. Je fais donc entrer la vérification dans le flux de travail : un build et une vérification de types après chaque passe, des tests qui échouent avant d'être corrigés, une relecture humaine avant publication. Un agent qui ne peut pas montrer ce qu'il a vérifié n'a pas terminé. Cela vaut aussi quand un agent bloque. Pendant la construction de ce site, un agent chargé de générer des images s'est heurté à une limite de son bac à sable. Il s'est arrêté, a décrit l'erreur et proposé deux façons de débloquer, au lieu de désactiver la protection de lui-même. C'est exactement le comportement que je veux installer : échouer clairement plutôt que réussir en apparence. ## Ce que cela donne sur un vrai projet : ce site Ce site a été construit par plusieurs agents, chacun avec un périmètre de fichiers attribué : l'un pour la structure des pages, l'autre pour l'expérience de lecture, un troisième pour le contenu. Ils se transmettaient des contrats écrits, ce que chacun avait livré, ce qu'il n'avait pas touché, ce qui restait ouvert. Chaque passe se terminait par un build et une vérification de types. Tout n'a pas été lisse. Un agent de contenu a été arrêté en cours de route ; le suivant a dû relire ses modifications partielles une à une au lieu de leur faire confiance. C'est précisément pour ce genre d'incident que les primitives existent : l'état était écrit, les règles aussi, et la reprise a été une relecture, pas une enquête. ## Ce que je n'installe pas Je n'arrive pas avec une pile d'outils à adopter en bloc. Je n'introduis pas d'agent sur des données de production sans frontière écrite. Je ne promets pas de gain de productivité avant de l'avoir mesuré. Et je ne demande pas à une équipe de renoncer à ce qui fait la fierté de son métier : les agents prennent les gestes mécaniques, les développeurs gardent le jugement. ## Par où commencer Si vous voulez essayer dans votre équipe, trois gestes suffisent pour démarrer : 1. **Écrire le fichier de contexte** de votre dépôt principal, en une page, et le relire en équipe. 2. **Choisir une procédure** qui revient chaque semaine, l'écrire comme une skill avec ses vérifications, et la confier à un agent sous supervision. 3. **Fixer une règle de preuve** : aucune modification d'agent n'est acceptée sans le build, les tests et une relecture humaine. Le reste vient avec l'usage. Et si vous voulez qu'on le fasse ensemble, c'est précisément le travail que je propose. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/articles/rejoindre-une-equipe-et-y-installer-des-primitives-agentiques *** --- title: "Automatiser un processus sensible sans perdre la traçabilité" description: "Automatiser un processus qui touche à la santé, à la paie ou à la facturation n’est pas une question de vitesse. C’est une question de mémoire : savoir, après coup, qui a décidé quoi, avec quelles règles et sur quelles données." url: "https://mc-stud.io/articles/automatiser-un-processus-sensible-sans-perdre-la-tracabilite" author: "Matisse Chenavas" date: "2026-10-08" lang: "fr" ai: "true" --- # Automatiser un processus sensible sans perdre la traçabilité > Automatiser un processus qui touche à la santé, à la paie ou à la facturation n’est pas une question de vitesse. C’est une question de mémoire : savoir, après coup, qui a décidé quoi, avec quelles règles et sur quelles données. 6 min de lecture ## L’essentiel - Sur un processus sensible, la bonne mesure n’est pas le temps gagné, mais la capacité à expliquer chaque décision six mois plus tard. - Résoudre la règle au moment de l’exécution, puis la figer avec elle : on corrige demain sans réécrire hier. - Un glossaire partagé coûte quelques heures et en économise beaucoup à chaque incident. - Le système prépare, une personne valide : la validation humaine est une étape vérifiée sur des données précises. - Chaque étape doit pouvoir être rejouée seule, sans doublon. Quand on automatise un processus, on pense d'abord au temps gagné. C'est légitime : personne ne regrette les heures passées à recopier des fiches ou à reformater des tableaux. Mais sur un processus sensible, celui qui touche à des données de santé, à la paie ou à la facturation, le temps gagné n'est pas la bonne mesure du succès. La bonne mesure, c'est la capacité à répondre, six mois plus tard, à une question simple : **pourquoi le système a-t-il fait cela ?** Un processus manuel a un avantage que l'on sous-estime : il laisse des traces humaines. Un email, une initiale sur un document, le souvenir d'un collègue. Ces traces sont imparfaites, mais elles existent. Une automatisation mal conçue les efface, et les remplace par une boîte noire qui agit vite, sans mémoire. C'est là que naissent la méfiance des équipes et les incidents impossibles à expliquer. Voici ce que j'ai appris en concevant des systèmes qui automatisent ce type de processus, notamment le remplissage de formulaires de service après-vente à partir de fichiers reçus, et la lecture de cartes de complémentaire santé. ## Séparer la règle de son exécution La première erreur consiste à confondre la règle et son application. Dans un système de routage, par exemple, une fiche reçue doit être dirigée vers un ou plusieurs formulaires selon son contenu. La tentation est de calculer la destination une fois, à la réception, et de ne plus y revenir. Le problème apparaît au premier changement de règle. Si la destination est calculée à la réception, toutes les fiches en attente gardent l'ancienne logique. Si elle est recalculée en permanence, on ne sait plus quelle règle a réellement produit un formulaire déjà rempli. La solution retenue sur le projet de routage SAV mené pour Santécie tient en deux principes. D'abord, **la destination se résout au moment de l'exécution**, avec les règles en vigueur à cet instant. Ensuite, **cette résolution est figée avec l'exécution** : chaque formulaire rempli garde la trace de la règle, et de la version de la règle, qui l'a produit. On peut corriger une règle demain sans réécrire l'histoire d'hier. Ce découplage a un coût : il faut versionner les règles, et accepter qu'une prévision affichée à l'écran ne fasse pas foi. J'ai d'ailleurs distingué explicitement la « projection » de routage, une prévision utile pour la consultation, de « l'affectation » réelle, calculée juste avant le remplissage. Cette distinction de vocabulaire a évité bien des malentendus avec les utilisateurs. ## Nommer les choses avant de les automatiser La traçabilité commence par le vocabulaire. Si l'équipe métier et l'équipe technique n'emploient pas les mêmes mots pour les mêmes choses, aucun historique ne sera lisible. Sur ce projet, j'ai tenu avec l'équipe un glossaire partagé, avec pour chaque terme une définition courte et les mots à éviter. Une « requête » n'est pas un « lot », une « exécution » n'est pas un « fichier », un « rejeu » n'est pas une « complétion ». Ces nuances paraissent pointilleuses. Elles deviennent essentielles le jour où un utilisateur demande pourquoi un formulaire a été rempli deux fois : la réponse dépend précisément de la différence entre rejouer une requête entière et compléter seulement ce qui avait échoué. Je recommande ce glossaire à toute organisation qui automatise un processus sensible. Il coûte quelques heures au départ et en économise beaucoup à chaque incident. ## Garder l'humain là où il apporte du jugement Automatiser ne veut pas dire tout automatiser. Sur un processus sensible, certaines décisions doivent rester humaines, parce qu'elles engagent l'organisation ou parce que la machine se trompe d'une façon qu'elle ne sait pas détecter. Le démonstrateur de lecture de cartes de complémentaire santé que j'ai conçu pour Santécie en est un bon exemple. Le système extrait le texte d'une carte et propose des champs métier. Mais chaque champ reste facultatif et modifiable, et **une personne vérifie avant toute confirmation**. Le système ne vérifie pas les droits et ne prend aucune décision automatisée. Il prépare ; l'humain valide. Ce principe vaut aussi pour mes propres opérations. Lorsque des agents préparent ma facturation mensuelle, ils rédigent les brouillons de facture et d'email, mais rien n'est envoyé sans mon accord explicite. La validation humaine n'est pas une formalité ajoutée à la fin : c'est une étape du processus, vérifiée sur des données précises, par exemple le montant, le destinataire ou la période, et non sur une impression générale. La question à se poser n'est donc pas « que peut-on automatiser ? », mais « où le jugement humain apporte-t-il quelque chose que la règle ne capture pas ? ». C'est là qu'il faut placer les points de validation. ## Garder les données là où elles doivent rester La traçabilité concerne aussi le chemin des données. Sur un processus qui manipule des données de santé, savoir où elles transitent est aussi important que savoir ce que le système en fait. Sur le projet de lecture de cartes, le traitement est conçu pour rester sur le poste de l'utilisateur. Le recours à un service externe n'est envisagé que pour le banc d'essai, et seulement avec une garantie de rétention nulle des données. Les échantillons réels ne sortent pas du cadre du client. Cette discipline a un prix : certains services, plus simples à brancher, sont écartés d'emblée. Mais elle permet de répondre clairement à la question qu'un responsable de la conformité posera tôt ou tard. ## Rendre chaque étape rejouable Un processus automatisé finira par échouer. Un fichier mal formé, un service indisponible, une règle incomplète. La question n'est pas d'éviter toute panne, mais de pouvoir reprendre proprement. Pour cela, chaque étape doit être identifiable et rejouable indépendamment. Si une fiche est routée vers trois formulaires et qu'un seul échoue, on doit pouvoir relancer ce seul formulaire, sans refaire les deux autres et sans créer de doublons. Sur le benchmark OCR, chaque version de pipeline produit des artefacts immuables : on peut comparer deux exécutions sans se demander si quelque chose a changé entre-temps. Ce n'est pas un raffinement technique. C'est ce qui permet à une équipe de corriger un incident en quelques gestes, au lieu de tout reprendre à la main et de perdre au passage la confiance dans l'outil. ## Écrire les décisions, pas seulement le code Dernier point, souvent négligé : les décisions d'architecture doivent être écrites. Pas dans un document de cinquante pages que personne ne lira, mais dans des notes courtes, une par décision, qui disent ce qui a été choisi, pourquoi, et quelles options ont été écartées. Sur le projet de lecture de cartes, onze décisions de ce type ont été consignées : la séparation entre pilotage et exécution, l'immutabilité des artefacts, les conditions d'usage d'une API externe, la cible de déploiement. Le jour où un auditeur, un nouveau développeur ou le client lui-même demande pourquoi le système fonctionne ainsi, la réponse existe déjà. ## Par où commencer Si vous envisagez d'automatiser un processus sensible, voici trois questions à poser avant d'écrire la moindre ligne de code : 1. **Que devra-t-on pouvoir expliquer dans six mois ?** Listez les questions qu'un auditeur, un client ou un collègue pourrait poser. Le système doit pouvoir y répondre. 2. **Où le jugement humain est-il irremplaçable ?** Placez là vos points de validation, et faites-en des étapes à part entière. 3. **Que se passe-t-il quand une étape échoue ?** Si la réponse est « on recommence tout », le système n'est pas prêt. L'automatisation utile ne retire pas l'humain du processus. Elle lui retire les gestes mécaniques, et lui laisse, avec une meilleure mémoire, ce qui demande du discernement. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/articles/automatiser-un-processus-sensible-sans-perdre-la-tracabilite *** --- title: "De l’idée au pilote : réussir un projet IA mesurable" description: "La plupart des projets d’IA ne meurent pas d’un mauvais modèle. Ils meurent d’un pilote sans critère de réussite. Voici comment je construis un pilote qui permet de décider." url: "https://mc-stud.io/articles/de-l-idee-au-pilote-reussir-un-projet-ia-mesurable" author: "Matisse Chenavas" date: "2026-10-01" lang: "fr" ai: "true" --- # De l’idée au pilote : réussir un projet IA mesurable > La plupart des projets d’IA ne meurent pas d’un mauvais modèle. Ils meurent d’un pilote sans critère de réussite. Voici comment je construis un pilote qui permet de décider. 5 min de lecture ## L’essentiel - Un pilote utile se termine par une décision : étendre, ajuster ou arrêter, sur des critères écrits au départ. - Construire de quoi comparer avant de choisir un modèle ou un fournisseur. - La confidentialité est une contrainte de conception, pas un détail réglé après le pilote. - Borner le modèle : contexte maîtrisé, accès en lecture seule, périmètre explicite. - Chaque correction humaine est une mesure ; les limites s’écrivent aussi clairement que les résultats. Beaucoup d'organisations ont déjà « testé l'IA ». Un assistant branché sur quelques documents, une démonstration convaincante en réunion, puis plus rien. Le pilote n'a pas échoué, à proprement parler. Il n'a simplement jamais permis de prendre une décision. C'est le symptôme le plus fréquent que je rencontre : un projet d'IA lancé à partir d'une technologie plutôt qu'à partir d'une question. On se demande ce qu'un modèle de langage pourrait faire, au lieu de se demander quel problème mérite d'être résolu, et comment on saura qu'il l'est. Voici la démarche que j'applique, nourrie par des projets concrets : un banc d'essai de lecture de cartes de complémentaire santé, un coach conversationnel intégré à une application d'entraînement, et des agents qui préparent une partie de mes propres opérations. ## Commencer par la décision, pas par le modèle Un pilote utile se termine par une décision : étendre, ajuster ou arrêter. Si personne ne sait, au lancement, sur quels critères cette décision sera prise, le pilote produira une impression, pas une réponse. Avant de choisir un modèle, j'écris donc trois choses avec le client. La **tâche précise** que le système doit accomplir, formulée en termes métier : lire tel champ sur tel document, répondre à telle catégorie de question. Le **critère de réussite**, mesurable sur des cas réels : une proportion de champs corrects, un temps de traitement, une part de réponses acceptables. Et la **condition d'arrêt** : ce qui, si on l'observe, signifie que l'approche ne convient pas. Cette dernière est la plus difficile à écrire, et la plus utile. Un pilote qui ne peut pas échouer ne peut rien démontrer. ## Construire de quoi comparer avant de choisir Le deuxième piège consiste à choisir un outil avant d'avoir de quoi le juger. Sur un sujet comme la lecture de documents, il existe des dizaines de solutions : services d'OCR hébergés, modèles de vision généralistes, modèles open-weight que l'on peut faire tourner chez soi. Chacune a ses forces, ses coûts et ses contraintes de confidentialité. Pour Santécie, plutôt que de brancher le service le plus connu et de le juger sur quelques exemples, j'ai d'abord construit un banc d'essai. Chaque pipeline y est versionné et produit des artefacts qui ne changent plus. On peut ainsi comparer deux moteurs, ou deux réglages du même moteur, sur les mêmes images, sans se demander si quelque chose a bougé entre les deux essais. Ce travail paraît lent au départ. En réalité, il accélère tout le reste : chaque nouvelle option se teste en quelques heures, et la discussion porte sur des résultats, pas sur des promesses commerciales. ## Traiter la confidentialité comme une contrainte de conception Sur des données sensibles, la question « où les données sont-elles traitées ? » n'est pas un détail à régler après le pilote. Elle détermine les options possibles. Dans le cas des cartes de complémentaire santé, le traitement est conçu pour rester sur le poste de l'utilisateur. Le recours à une API externe n'est envisagé que pour le banc d'essai, et seulement avec une garantie de rétention nulle. Une partie du travail a consisté à analyser les offres d'OCR hébergées sous contrainte HDS, leurs engagements de confidentialité, et les conditions dans lesquelles un modèle open-weight pourrait être servi sur une infrastructure maîtrisée. Ce cadrage écarte d'emblée certaines solutions. C'est précisément son intérêt : le pilote ne débouchera pas sur une option que la conformité refusera ensuite. ## Borner ce que le modèle peut faire Un modèle de langage branché sans limites produit vite des réponses plausibles mais fausses. Sur un sujet qui touche à la santé ou à l'argent, ce n'est pas acceptable. Dans l'application d'entraînement développée pour Essan NFC, le coach conversationnel ne répond pas « de mémoire ». Il récupère le contexte de l'utilisateur au moyen de commandes en lecture seule, procède par cycles de recherche bornés, et ne peut rien modifier. Il s'appuie sur ce qui est connu de l'utilisateur et de la méthode, pas sur des généralités. Les conseils restent par ailleurs informatifs : ils ne remplacent pas un avis médical, et l'application le dit. Le projet a aussi exploré l'exécution d'un modèle compact directement sur le téléphone, pour la confidentialité et le fonctionnement hors ligne. Cette piste est restée une expérimentation de développement : elle a permis de mesurer les contraintes réelles (taille, rapidité, qualité) sans les imposer au produit. C'est exactement le rôle d'une exploration : apprendre quelque chose qui peut changer une décision, sans se transformer en engagement implicite. ## Mettre la validation humaine dans le processus Un pilote d'IA qui fonctionne pose immédiatement une autre question : qui est responsable de ce que le système produit ? Ma réponse est constante : **le système prépare, une personne valide**. Sur le démonstrateur de lecture de cartes, chaque champ proposé est vérifié par un humain avant confirmation. Dans mes propres opérations, des agents préparent les brouillons de facture et d'email, mais rien ne part sans mon accord. Cette validation n'est pas un bouton ajouté à la fin : c'est une étape du processus, conçue dès le départ, et vérifiée sur des données précises. Ce choix a une conséquence heureuse sur la mesure. Chaque correction humaine est une donnée : elle dit où le système se trompe, et à quelle fréquence. Le pilote produit ainsi, en fonctionnant, les indicateurs qui permettront de décider de son extension. ## Écrire les limites aussi clairement que les résultats Le dernier point est une question d'honnêteté, et de crédibilité. Un pilote produit des résultats partiels. Les présenter comme définitifs, c'est préparer la déception. Je rédige donc chaque synthèse de pilote avec une section consacrée aux limites : ce qui n'a pas été testé, les cas où le système échoue, les hypothèses qui restent à vérifier. Sur le banc d'essai OCR, par exemple, la documentation affirme explicitement qu'il s'agit d'un démonstrateur, sans revendication de qualité de production ni de conformité médicale. Cette transparence n'affaiblit pas le projet. Elle permet au client de décider en connaissance de cause. ## La démarche en résumé 1. **Formuler la décision** que le pilote doit permettre, avec un critère de réussite et une condition d'arrêt. 2. **Construire de quoi comparer** avant de choisir un modèle ou un fournisseur. 3. **Fixer le cadre de confidentialité** dès le départ, pour ne pas explorer des options inutilisables. 4. **Borner le modèle** : contexte maîtrisé, accès en lecture seule, périmètre explicite. 5. **Intégrer la validation humaine** comme étape du processus, et en faire une source de mesure. 6. **Documenter les limites** avec autant de soin que les résultats. Un projet d'IA mesurable n'est pas plus lent qu'un autre. Il évite simplement de recommencer, six mois plus tard, le même pilote sans conclusion. --- Matisse Chenavas, Fondateur de MC Studio. https://mc-stud.io/articles/de-l-idee-au-pilote-reussir-un-projet-ia-mesurable *** --- title: "pennylane-cli, un CLI Pennylane pour agents" description: "Un CLI pensé pour les agents, qui expose l’API Pennylane v2 en commandes à sortie JSON, avec une porte de sortie pour les requêtes brutes." url: "https://mc-stud.io/open-source/pennylane-cli" lang: "fr" updated: "2026-10-12" --- Bêta CLI comptabilité Pennylane agents # pennylane-cli Un CLI pensé pour les agents, qui expose l’API Pennylane v2 en commandes à sortie JSON, avec une porte de sortie pour les requêtes brutes. Installer `git clone https://github.com/ZEDIUM-Off/pennylane-cli && cd pennylane-cli && pip install -e .` Outils jeunes : lisez le README du dépôt avant d’installer. **2** commits / 12 mois **Dernière version** v0.1 **étoile** 0 **fork** 0 **contributeur** 1 **ticket ouvert** 0 **Dernier commit** 11 octobre 2026 Commits par mois. 12 derniers mois, échelle propre à chaque dépôt. Chiffres GitHub relevés le 12 octobre 2026. **Code source** [github.com/ZEDIUM-Off/pennylane-cli](https://github.com/ZEDIUM-Off/pennylane-cli) **Licence** Licence MIT **Statut** Bêta ## Ce que ça fait pennylane-cli expose les opérations de l’API Pennylane Company v2 sous forme de commandes en ligne, avec une sortie JSON qu’un agent lit sans ambiguïté. Les 160 opérations visibles de la spécification OpenAPI sont couvertes, et une commande de requête brute sert de porte de sortie pour le reste. Je l’ai construit pour mes propres opérations, où des agents préparent des brouillons de facture que je valide avant tout envoi. Le CLI s’installe depuis un clone local du dépôt. [Code source](https://github.com/ZEDIUM-Off/pennylane-cli) ## Quand s’en servir - Un agent doit lire ou préparer des données comptables dans Pennylane. - Vous voulez des commandes prévisibles, à sortie JSON, plutôt qu’un appel HTTP improvisé. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: ".pi, ma configuration de contexte pour Pi" description: "Ma configuration de contexte pour l’agent Pi, dans sa partie publique : des normes compactes pour agents, injectées par pi-⁠context-⁠tree." url: "https://mc-stud.io/open-source/pi-config" lang: "fr" updated: "2026-10-12" --- Expérimental Pi contexte normes configuration # .pi Ma configuration de contexte Pi, dans sa partie publique : des normes compactes pour agents (responsabilité, contrats, exécution, piles techniques), injectées par pi-⁠context-⁠tree. Installer `git clone https://github.com/ZEDIUM-Off/.pi.git ~/pi-config` Outils jeunes : lisez le README du dépôt avant d’installer. **9** commits / 12 mois **Dernière version** v0.1.0 **étoile** 1 **fork** 0 **contributeur** 1 **ticket ouvert** 0 **Dernier commit** 11 octobre 2026 Commits par mois. 12 derniers mois, échelle propre à chaque dépôt. Chiffres GitHub relevés le 12 octobre 2026. **Code source** [github.com/ZEDIUM-Off/.pi](https://github.com/ZEDIUM-Off/.pi) **Licence** Licence MIT **Statut** Expérimental ## Ce que ça fait Ce dépôt publie la partie partageable de ma configuration Pi. Il contient un `CONTEXT.json` et une série de normes compactes : principes généraux, responsabilité, contrats, comportement de l’agent, déroulé d’exécution, et des règles par pile technique (TypeScript, web, systèmes). pi-context-tree les injecte au bon moment. Il est public par défaut, avec une liste blanche de fichiers publiables ; aucun identifiant n’y est synchronisé. Clonez-le à part pour vous en inspirer, plutôt que par-dessus une configuration existante : le README décrit les deux cas. [Code source](https://github.com/ZEDIUM-Off/.pi) ## Quand s’en servir - Vous cherchez un exemple concret de normes d’agent courtes et versionnées. - Vous voulez structurer un contexte déterministe et auditable dans votre propre configuration. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "pi-context-tree, contexte par chemin pour Pi" description: "Une extension de l’agent Pi qui injecte le bon contexte au bon moment, selon le chemin et l’opération, depuis des fichiers CONTEXT.json versionnés." url: "https://mc-stud.io/open-source/pi-context-tree" lang: "fr" updated: "2026-10-12" --- Bêta Pi contexte AGENTS.md gouvernance # pi-context-tree Une extension pour l’agent de code Pi qui injecte le bon contexte au bon moment, selon le chemin et l’opération, à partir de fichiers CONTEXT.json versionnés dans le dépôt. Installer `pi install git:github.com/ZEDIUM-Off/pi-context-tree` Outils jeunes : lisez le README du dépôt avant d’installer. **12** commits / 12 mois **Dernière version** v0.4.2 **étoile** 0 **fork** 0 **contributeur** 1 **ticket ouvert** 0 **Dernier commit** 4 mai 2026 Commits par mois. 12 derniers mois, échelle propre à chaque dépôt. Chiffres GitHub relevés le 12 octobre 2026. **Code source** [github.com/ZEDIUM-Off/pi-context-tree](https://github.com/ZEDIUM-Off/pi-context-tree) **Licence** Licence MIT **Statut** Bêta ## Ce que ça fait pi-context-tree sort le routage du contexte du comportement du modèle pour le placer dans la configuration du dépôt. Au lieu de demander à l’agent de penser à lire la documentation, chaque dossier déclare, dans un fichier `CONTEXT.json`, quels fichiers ou quelles URL injecter pour quel chemin et quelle opération. Les règles se déclenchent sur des événements précis (début de session, démarrage d’agent, appel d’outil, lancement de sous-agent), avec des budgets pour borner ce qui est injecté. L’extension embarque des skills de configuration et d’audit, et des commandes pour vérifier l’état et valider la configuration. C’est une primitive que je recommande aux équipes : le contexte devient déterministe, auditable, et il vit à côté du code qu’il décrit. [Code source](https://github.com/ZEDIUM-Off/pi-context-tree) ## Quand s’en servir - Vos agents oublient les règles du projet dès que la conversation s’allonge. - Vous dépensez des tokens à charger un prompt global qui ne concerne qu’une partie du dépôt. - Vous voulez que le contexte injecté se relise en revue, comme du code. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "pi-runtime-monitor, moniteur de sous-agents Pi" description: "Une extension Pi légère qui affiche, dans le pied de page, le processeur, la mémoire et l’usage cumulé des sous-agents de votre session." url: "https://mc-stud.io/open-source/pi-runtime-monitor" lang: "fr" updated: "2026-10-12" --- Bêta Pi sous-agents supervision # pi-runtime-monitor Une extension Pi légère qui affiche, dans le pied de page, le processeur, la mémoire et l’usage cumulé des sous-agents de votre session. Installer `pi install git:github.com/ZEDIUM-Off/pi-runtime-monitor` Outils jeunes : lisez le README du dépôt avant d’installer. **3** commits / 12 mois **Dernière version** v0.1.1 **étoile** 0 **fork** 0 **contributeur** 1 **ticket ouvert** 0 **Dernier commit** 20 juillet 2026 Commits par mois. 12 derniers mois, échelle propre à chaque dépôt. Chiffres GitHub relevés le 12 octobre 2026. **Code source** [github.com/ZEDIUM-Off/pi-runtime-monitor](https://github.com/ZEDIUM-Off/pi-runtime-monitor) **Licence** Licence MIT **Statut** Bêta ## Ce que ça fait pi-runtime-monitor ajoute au pied de page de Pi une ligne d’état : identifiant du processus, processeur, mémoire résidente, et usage agrégé des sous-agents liés à la session. Les mesures sont échantillonnées toutes les deux secondes. L’extension n’a aucune dépendance à l’exécution, aucun accès réseau, aucune télémétrie et ne stocke rien. Elle se recharge dans une session déjà ouverte avec `/reload`, et se retire avec `pi remove`. [Code source](https://github.com/ZEDIUM-Off/pi-runtime-monitor) ## Quand s’en servir - Vous lancez plusieurs sous-agents en parallèle et voulez voir ce qu’ils coûtent à la machine. - Une session devient lente et vous cherchez qui consomme quoi. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "plan-writer, skill de plan d’implémentation" description: "Mes skills partagées pour agents, installables avec le CLI skills ; pour l’instant plan-⁠writer, qui aide à rédiger des plans d’implémentation structurés." url: "https://mc-stud.io/open-source/skills" lang: "fr" updated: "2026-10-12" --- Expérimental skills planification agents # plan-writer Mes skills partagées pour agents, installables avec le CLI skills ; pour l’instant plan-⁠writer, qui aide à rédiger des plans d’implémentation structurés. Installer `npx skills add ZEDIUM-Off/skills` Outils jeunes : lisez le README du dépôt avant d’installer. **4** commits / 12 mois **étoile** 0 **fork** 0 **contributeur** 1 **ticket ouvert** 0 **Dernier commit** 11 octobre 2026 Commits par mois. 12 derniers mois, échelle propre à chaque dépôt. Chiffres GitHub relevés le 12 octobre 2026. **Code source** [github.com/ZEDIUM-Off/skills](https://github.com/ZEDIUM-Off/skills) **Licence** Licence MIT **Statut** Expérimental ## Ce que ça fait Ce dépôt réunit les skills que je choisis de publier. Pour l’instant, il en contient une seule : plan-writer, qui guide l’agent dans la rédaction d’un plan d’implémentation structuré, que l’on peut relire et discuter avant la première ligne de code. L’installation passe par le CLI `skills`, qui copie les skills du dépôt et les rend disponibles pour votre agent compatible. Les autres skills de mon atelier restent privées tant qu’elles ne sont pas assez génériques pour servir ailleurs. [Code source](https://github.com/ZEDIUM-Off/skills) ## Quand s’en servir - Vous voulez que l’agent produise un plan relisible avant d’écrire du code. - Vous cherchez un exemple de skill courte, centrée sur une seule procédure. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "Zedflow, moteur de flux d’agents typés" description: "Un moteur et un studio locaux pour des flux d’agents typés : graphe validé avant exécution, validations humaines et trace de chaque tour." url: "https://mc-stud.io/open-source/zedflow" lang: "fr" updated: "2026-10-12" --- Expérimental flux d’agents Rust graphes validation humaine # Zedflow Un moteur et un studio locaux pour des flux d’agents typés : chaque flux est un graphe validé avant exécution, avec contexte maîtrisé, validations humaines et trace de chaque tour. Installer `git clone https://github.com/ZEDIUM-Off/zedflow && cd zedflow && pnpm --dir web install --frozen-lockfile && pnpm --dir web build` Outils jeunes : lisez le README du dépôt avant d’installer. **678** commits / 12 mois **Dernière version** v0.2.0 **étoile** 0 **fork** 0 **contributeur** 1 **tickets ouverts** 33 **Dernier commit** 3 octobre 2026 Commits par mois. 12 derniers mois, échelle propre à chaque dépôt. Chiffres GitHub relevés le 12 octobre 2026. **Code source** [github.com/ZEDIUM-Off/zedflow](https://github.com/ZEDIUM-Off/zedflow) **Licence** Source disponible, usage non commercial (PolyForm Noncommercial 1.0.0) **Statut** Expérimental ## Ce que ça fait Zedflow est un moteur et un studio pour harness d’agents. Un flux est un graphe strict et typé, validé avant de s’exécuter. Avant chaque appel au modèle, une stratégie de contexte compose exactement ce que l’agent reçoit ; l’état vit dans des magasins typés, pas dans le prompt. Des passerelles relient les flux entre eux, et chaque tour est tracé. Le studio web permet de dessiner les flux, de régler les stratégies de contexte, de lancer des exécutions et d’inspecter chaque tour. Le CLI `zf` valide, compile et exécute les mêmes définitions. La commande ci-dessus construit le studio ; le démon se lance ensuite avec Cargo, comme décrit dans le README, avec un fournisseur de démonstration qui ne demande ni compte ni modèle réel. Zedflow est en préversion et sous licence PolyForm Noncommercial : l’usage commercial demande un accord séparé. [Code source](https://github.com/ZEDIUM-Off/zedflow) ## Quand s’en servir - Une seule boucle d’agent ne suffit plus et vous voulez composer des flux spécialisés. - Vous devez pouvoir relire ce que chaque agent a reçu et fait, tour par tour. - Certaines étapes doivent attendre une validation humaine sur des données précises. ## Parlons de ce que l’IA pourrait changer chez vous Un échange découverte de 30 minutes, en visio et sans engagement, pour parler de votre projet, de vos contraintes et de la meilleure suite à lui donner. [Réserver un échange](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=Premier%20%C3%A9change) *** --- title: "Mentions légales" description: "Éditeur, hébergeur et informations légales du site mc-stud.io (MC Studio, EURL)." url: "https://mc-stud.io/mentions-legales" lang: "fr" updated: "2026-10-12" --- Informations légales # Mentions légales Qui édite ce site, qui l’héberge et comment me joindre. Ces informations sont publiées conformément à l’article 6 de la loi du 21 juin 2004 pour la confiance dans l’économie numérique. ## Éditeur du site **Dénomination** MC Studio (MCS) **Forme juridique** entreprise unipersonnelle à responsabilité limitée (EURL) **Capital social** 1 000 € **Siège social** 47 impasse du Bergeron, 38290 Frontonas, France **SIREN** [100 627 207](https://annuaire-entreprises.data.gouv.fr/entreprise/100627207) **SIRET** [100 627 207 00010](https://annuaire-entreprises.data.gouv.fr/entreprise/100627207) **Immatriculation** RCS Vienne 100 627 207 **TVA intracommunautaire** FR 76 100627207 **Directeur de la publication** Matisse Chenavas, gérant **Courriel** [contact@mc-stud.io](mailto:contact@mc-stud.io) **Téléphone** [06 51 09 63 02](tel:+33651096302) ## Hébergement **Hébergeur** [Cloudflare, Inc.](https://www.cloudflare.com/) **Adresse** 101 Townsend St, San Francisco, CA 94107, USA **Téléphone** +1 (650) 319-8930 ## Propriété intellectuelle Les textes, visuels et éléments graphiques de ce site sont la propriété de MC Studio, sauf mention contraire (logos de clients et de technologies, qui restent la propriété de leurs titulaires et ne sont affichés qu’à titre d’illustration de mon travail). Toute reproduction ou réutilisation par une personne, au-delà de la courte citation, nécessite mon accord écrit préalable. L’exploration de ce site par les robots d’indexation et d’entraînement nommés dans le fichier robots.txt est en revanche autorisée, y compris pour l’entraînement de modèles : ce fichier fait foi de ma décision. Les portraits de Matisse Chenavas présentés sur ce site sont des images générées par IA à partir de ses propres photographies. Les outils présentés sur ce site restent soumis à la licence indiquée dans leur dépôt. Les composants logiciels, les polices, le modèle de recherche et les logos de technologies repris ici, avec leurs licences et leurs auteurs, sont listés dans la page [crédits et licences](https://mc-stud.io/credits). ## Responsabilité et liens externes Je veille à l’exactitude des informations publiées, sans pouvoir garantir leur exhaustivité ni leur actualité. Ce site renvoie vers des sites tiers (LinkedIn, GitHub, Google Agenda pour la prise de rendez-vous, Hugging Face pour le modèle de recherche) dont je ne contrôle pas le contenu ni les pratiques. ## Données personnelles Le traitement des données personnelles est décrit dans la [politique de confidentialité](https://mc-stud.io/confidentialite). Ce site ne dépose de cookie de mesure d’audience qu’avec votre accord, que vous pouvez retirer à tout moment depuis le pied de page. ## Accessibilité Je m’efforce de rendre ce site lisible et utilisable par tous (navigation au clavier, contrastes, texte alternatif, respect des préférences de mouvement). Si vous rencontrez un obstacle, écrivez-moi à [contact@mc-stud.io](mailto:contact@mc-stud.io) : je corrigerai ou proposerai une alternative. ## Droit applicable Ce site est soumis au droit français. Les juridictions françaises sont compétentes, sous réserve des règles impératives applicables. Dernière mise à jour : 12 octobre 2026 *** --- title: "Politique de confidentialité" description: "Quelles données personnelles traite ce site, pourquoi, combien de temps et comment exercer vos droits." url: "https://mc-stud.io/confidentialite" lang: "fr" updated: "2026-10-12" --- Données personnelles # Politique de confidentialité Ce site ne collecte presque rien : pas de formulaire, et une mesure d’audience qui ne s’active qu’avec votre accord. Voici ce qui est traité, et vos droits. ## Responsable du traitement MC Studio, EURL, représentée par son gérant Matisse Chenavas, dont les coordonnées figurent dans les [mentions légales](https://mc-stud.io/mentions-legales). Contact pour toute question sur vos données : [contact@mc-stud.io](mailto:contact@mc-stud.io). Aucun délégué à la protection des données n’est désigné. ## Ce que ce site ne fait pas - aucun cookie de mesure déposé, ni aucune requête vers Google, tant que vous n’avez pas accepté (seul votre choix est mémorisé, voir plus bas) ; - aucune publicité, aucun suivi publicitaire : les signaux publicitaires de Google restent refusés, même si vous acceptez la mesure d’audience ; - aucune police, vidéo ou carte chargée depuis un service tiers : les polices sont hébergées avec le site ; - aucun formulaire : on me contacte par courriel ou par un lien de prise de rendez-vous. ## Cookies et mesure d’audience Votre choix. Au premier passage, un bandeau vous propose d’accepter ou de refuser la mesure d’audience, avec la même facilité. Votre choix est mémorisé dans le stockage local de votre navigateur (clé mcs-consent : accord ou refus et date) pendant 6 mois au plus, puis la question vous est reposée. Ce stockage est strictement nécessaire pour respecter votre choix : il n’est jamais transmis et n’exige pas de consentement. Le lien « Gérer les cookies » en pied de page rouvre le choix à tout moment. Mesure d’audience, avec votre accord uniquement. Si vous acceptez, le site charge directement la balise Google de Google Analytics 4 (Google Ireland Limited pour l’Espace économique européen, Google LLC aux États-Unis). Finalité : savoir quelles pages sont lues et d’où viennent les visiteurs, pour améliorer le site. Base légale : votre consentement (RGPD, article 6, 1, a ; article 82 de la loi Informatique et Libertés). Données : pages consultées, date, type d’appareil et de navigateur, provenance, localisation approximative et un identifiant pseudonyme stocké dans les cookies _ga et _ga_KQZQ94SPP8. Selon Google, Google Analytics ne journalise ni ne stocke les adresses IP. Je suis responsable de ce traitement ; Google agit comme sous-traitant pour Google Analytics. Durées. Cookies Google : 13 mois au plus. Données dans Google Analytics : 14 mois au plus, puis suppression automatique. Votre choix de consentement : 6 mois. Retirer votre accord. Choisissez « Refuser » dans « Gérer les cookies » : les cookies Google sont supprimés, la page est rechargée et plus rien n’est envoyé à Google. Le retrait ne remet pas en cause les traitements déjà effectués. Vous pouvez aussi supprimer les cookies depuis les réglages de votre navigateur. Recherche sur le site. La recherche par mots-clés fonctionne entièrement dans votre navigateur : vos requêtes ne sont envoyées nulle part. Le site n’écrit jamais ce que vous tapez dans l’adresse de la page : sur la page de recherche, il est repris dans la partie du lien située après le « # », que votre navigateur ne transmet jamais à un serveur, et cette partie n’est pas écrite si vous avez accepté la mesure d’audience. Une exception d’un ancien lien partagé : s’il contient « ?q= », cette adresse parvient à l’hébergeur comme n’importe quelle requête, avant que la page ne l’efface de la barre d’adresse et n’en fasse un état interne ; la page l’efface avant que le moindre code Google ne soit chargé, et le code Google n’en reçoit jamais l’adresse complète. Si vous activez la recherche sémantique, après avoir lu l’encadré qui l’explique et cliqué sur « Télécharger et activer », votre navigateur télécharge une fois un modèle d’intelligence artificielle (EmbeddingGemma 2 de Google, licence Apache 2.0, environ 165 Mo) depuis Hugging Face, le dépôt où Google publie ses modèles, le garde dans son cache (Cache Storage) et l’exécute localement. Ce téléchargement est une requête de votre navigateur vers un tiers : Hugging Face, Inc. (société américaine) et son réseau de diffusion reçoivent alors votre adresse IP et les données techniques habituelles d’une requête (navigateur, date), mais ni votre recherche ni la page que vous consultez : seul le nom du site (mc-stud.io) accompagne la requête. Aucune requête vers Hugging Face n’est faite avant ce clic. Ensuite, le modèle est lu depuis votre cache, sans nouvelle requête, tant que les fichiers y restent ; si votre navigateur en a effacé tout ou partie, la page vous le redemande avant de les télécharger de nouveau. Une exception, pour un téléchargement que vous avez confirmé : si la page est rechargée ou fermée avant la fin, le téléchargement reprend de lui-même, à partir des parties déjà vérifiées, dès que vous ouvrez une page du site dans les 24 heures qui suivent, sauf si vous l’annulez (« Annuler le téléchargement » dans les détails de la recherche, ou le commutateur « Recherche sémantique » remis sur arrêt, dans n’importe quel onglet). Un téléchargement qui a échoué, qui a été annulé ou qui date de plus de 24 heures, ou dont le navigateur a effacé les fichiers, est redemandé avant toute nouvelle requête vers Hugging Face. Si votre navigateur refuse de conserver le modèle (stockage plein, navigation privée), la page vous en avertit et le modèle devra être téléchargé de nouveau, après votre accord, à une prochaine visite. Le traitement par Hugging Face est régi par sa propre politique de confidentialité : [huggingface.co/privacy](https://huggingface.co/privacy). Dans la recherche, le commutateur remis sur arrêt conserve les fichiers du modèle, tandis que « Supprimer le modèle de ce navigateur » les efface et oublie votre choix. Le moteur d’exécution (WebAssembly, 22 à 34 Mo) et le manifeste restent servis par ce site. Votre préférence est mémorisée dans le stockage local (clé mcs-search-semantic) et sert uniquement la fonction que vous avez demandée. Pendant un téléchargement, un second repère y est écrit (clé mcs-search-semantic-resume : l’empreinte du modèle, l’heure de votre confirmation et, une fois la première partie enregistrée, un indicateur) ; il permet la reprise décrite ci-dessus, expire au bout de 24 heures et disparaît dès que le téléchargement se termine, échoue ou est annulé. Vous pouvez supprimer ces repères, ainsi que le modèle, depuis la recherche ou les réglages de votre navigateur. ## Les traitements réels Courriels. Lorsque vous m’écrivez à [contact@mc-stud.io](mailto:contact@mc-stud.io), je traite votre adresse, votre nom éventuel et le contenu de votre message pour vous répondre et, le cas échéant, préparer une collaboration. Bases légales : mesures précontractuelles à votre demande, puis mon intérêt légitime à échanger avec mes interlocuteurs professionnels (RGPD, article 6, 1, b et f). Durée : le temps de l’échange, puis au plus trois ans après le dernier contact si aucun contrat n’est conclu ; pour un contrat, la durée légale de conservation des pièces comptables et contractuelles. La messagerie est opérée par un prestataire de courrier électronique agissant pour mon compte. Prise de rendez-vous. Le bouton de réservation est un lien vers la page de rendez-vous de [Google Agenda](https://calendar.google.com/), sur le site de Google. Le bouton de réservation ne charge rien depuis Google tant que vous ne le suivez pas ; ensuite, si vous réservez, vos informations de réservation (nom, adresse électronique, créneau) sont traitées sur le site de Google, selon sa propre politique de confidentialité, et je les reçois dans mon agenda pour honorer le rendez-vous. Même base légale et mêmes durées que ci-dessus. Journaux techniques de l’hébergeur. Comme tout serveur web, l’hébergeur ([Cloudflare, Inc.](https://www.cloudflare.com/)) enregistre des données de connexion (adresse IP, date, page demandée, type de navigateur) pour acheminer le site et le protéger contre les abus. Je n’y accède pas à titre nominatif et je n’en tire aucune statistique de visiteurs. Base légale : intérêt légitime à la sécurité et au bon fonctionnement du site. Durée de conservation : Cloudflare ne publie pas de durée unique pour les journaux de requêtes de son réseau ; sa politique de confidentialité indique qu’il conserve les données personnelles le temps nécessaire à ses finalités ou à ses obligations légales. Si les journaux applicatifs de Cloudflare Workers sont activés pour ce site, ils sont conservés 3 jours (offre gratuite) ou 7 jours (offre payante), selon la documentation de Cloudflare. Je ne les exporte ni ne les archive ailleurs. ## Destinataires et transferts hors de l’Union européenne Vos données ne sont ni vendues ni cédées. Elles sont accessibles à moi-même et aux prestataires techniques qui interviennent pour mon compte (messagerie, agenda, hébergement, mesure d’audience avec votre accord). Google (Analytics, avec votre accord ; Agenda, si vous réservez) et Cloudflare sont des sociétés américaines : les transferts s’appuient sur le Data Privacy Framework UE-États-Unis auquel elles adhèrent, ou à défaut sur les clauses contractuelles types de la Commission européenne. Hugging Face, Inc. (société américaine) n’est un destinataire que si vous activez la recherche sémantique après avoir cliqué sur « Télécharger et activer » : votre navigateur lui envoie alors directement une requête de téléchargement, qui lui révèle votre adresse IP et les données techniques de la requête, sous sa propre politique de confidentialité. Je n’invoque aucun mécanisme de transfert particulier pour ce téléchargement ; c’est pourquoi il reste soumis à votre choix explicite. ## Vos droits Vous pouvez demander l’accès à vos données, leur rectification, leur effacement, la limitation du traitement, vous y opposer, ou en demander la portabilité (RGPD, articles 15 à 21). Écrivez à [contact@mc-stud.io](mailto:contact@mc-stud.io) ; je réponds dans un délai d’un mois. Si vous estimez que vos droits ne sont pas respectés, vous pouvez saisir la [CNIL](https://www.cnil.fr/fr/plaintes) (3 place de Fontenoy, TSA 80715, 75334 Paris Cedex 07). Fournir vos données est facultatif : sans elles, je ne peux simplement pas répondre à votre demande. Aucune décision automatisée, ni profilage, n’est mise en œuvre. ## Évolutions Si le site ajoute un jour un nouvel outil de mesure ou un contenu tiers, cette page sera mise à jour avant sa mise en service, et un consentement sera demandé lorsque la loi l’exige. Dernière mise à jour : 12 octobre 2026 *** --- title: "Crédits et licences" description: "Composants logiciels, polices, modèle de recherche et logos de technologies utilisés par ce site, avec leurs auteurs, leurs licences et les modifications apportées." url: "https://mc-stud.io/credits" lang: "fr" updated: "2026-10-12" --- Informations légales # Crédits et licences Ce site repose sur des composants libres et sur des logos de tiers. Voici ce qui est réellement distribué avec les pages, qui en est l’auteur, sous quelle licence, et ce que j’ai modifié. ## Composants logiciels et modèle de recherche Les scripts envoyés à votre navigateur et les fichiers de la recherche sémantique incorporent les composants suivants. Chacun est utilisé selon les termes de sa licence ; leurs avis de droit d’auteur sont reproduits ici. - **React** (version 19.2.8) — interface des îlots interactifs. Licence : MIT. Copyright (c) Meta Platforms, Inc. and affiliates. [react.dev](https://react.dev/) - **React DOM** (version 19.2.8) — interface des îlots interactifs. Licence : MIT. Copyright (c) Meta Platforms, Inc. and affiliates. [react.dev](https://react.dev/) - **Motion** (version 14.0.0) — animations des îlots interactifs. Licence : MIT. Copyright (c) 2024 Motion B.V. [motion.dev](https://motion.dev/) - **Astro** (version 7.3.8) — moteur du site : navigation entre les pages et chargement des scripts. Licence : MIT. Copyright (c) 2021 Fred K. Schott Copyright (c) 2020 these people Copyright (c) 2019-present, Yuxi (Evan) You and Vite contributors [astro.build](https://astro.build/) - **Lumos for Astro** (version 0.0.5) — composants Astro, styles et utilitaires de l’interface (port Lumos pour Astro). Licence : MIT. Copyright (c) 2026 Timothy Ricks [github.com](https://github.com/lumosframework/lumos-for-astro) - **Fancy Components** — animations de texte et de chiffres, adaptées de Fancy Components. Licence : MIT. Copyright (c) 2024 Daniel Petho [fancycomponents.dev](https://www.fancycomponents.dev/) - **LiteRT-LM web runtime** (version 0.18.0) — moteur d’exécution du modèle de recherche sémantique, servi par ce site. Licence : Apache 2.0. Google LLC [github.com](https://github.com/google-ai-edge/LiteRT-LM) · [Texte de la licence Apache 2.0](https://mc-stud.io/search-model/LICENSE) · [Avis (NOTICE)](https://mc-stud.io/search-model/NOTICE) - **EmbeddingGemma 2 (270M)** — modèle de recherche sémantique, téléchargé depuis Hugging Face après votre accord. Licence : Apache 2.0. Google LLC [huggingface.co](https://huggingface.co/google/embeddinggemma-2) · [Texte de la licence Apache 2.0](https://mc-stud.io/search-model/LICENSE) · [Avis (NOTICE)](https://mc-stud.io/search-model/NOTICE) ## Polices Les textes sont composés en Sora et en Inter, hébergées avec le site, sous la licence SIL Open Font License 1.1 (texte complet plus bas). - **Inter** (version 5.3.0) — police de texte. Licence : SIL OFL 1.1. Copyright 2016 The Inter Project Authors (https://github.com/rsms/inter) [rsms.me](https://rsms.me/inter/) - **Sora** (version 5.3.0) — police des titres. Licence : SIL OFL 1.1. Copyright 2019 The Sora Project Authors (https://github.com/sora-xor/sora-font) [github.com](https://github.com/sora-xor/sora-font) ## Logos de technologies Les logos de technologies viennent du paquet simple-icons (CC0 1.0, domaine public) ; les marques elles-mêmes restent la propriété de leurs titulaires et ne sont affichées que pour désigner la technologie. Deux logos sont soumis à des conditions d’attribution, indiquées ci-dessous. - **Rust** — Auteur : Rust Foundation. Licence : [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). Le fichier fourni par simple-icons 16.35.0 porte la licence CC BY-SA 4.0. La politique de marques de la Rust Foundation, consultée le 12 octobre 2026, place les logos Rust et Cargo sous Creative Commons Attribution (CC BY). J’applique les conditions les plus strictes (CC BY-SA 4.0). Modifications : Version monochrome à tracé unique distribuée par simple-icons, couleur de remplissage fixée à #000000, redimensionnée à l’affichage. Source : [rust-lang.org](https://www.rust-lang.org/) · [rustfoundation.org](https://rustfoundation.org/policy/rust-trademark-policy/) - **Git** — Auteur : Jason Long. Licence : [CC BY 3.0](https://creativecommons.org/licenses/by/3.0/). Creative Commons Attribution 3.0 (CC BY 3.0). Modifications : Version monochrome à tracé unique distribuée par simple-icons, couleur de remplissage fixée à #F03C2E, redimensionnée à l’affichage. Source : [git-scm.com](https://git-scm.com/) · [git-scm.com](https://git-scm.com/community/logos) - **Autres logos de technologies** : TypeScript, React, Astro, Node.js, NestJS, Python, PostgreSQL, Docker, NVIDIA, Expo, Coder, Anthropic / Claude, Ollama, vLLM, Hugging Face, Cloudflare, Railway, GitHub, LangChain, Medusa, Pinia, Prisma. ## Logos de clients et de partenaires Les logos des clients et des partenaires restent la propriété de leurs titulaires. Ils sont repris de leurs sites officiels, sans licence libre, à titre d’illustration de mon travail. Essan NFC, Santécie, Silico, CICP2R, Cesatec. ## Texte des licences Voici le texte de la licence MIT, qui s’applique aux composants marqués MIT, puis celui de la SIL Open Font License 1.1. La licence Apache 2.0, qui s’applique au modèle et au moteur d’exécution de la recherche, est servie par ce site avec son avis. ### MIT ``` Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ``` ### SIL Open Font License 1.1 ``` This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL ----------------------------------------------------------- SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ----------------------------------------------------------- PREAMBLE The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects, to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others. The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. The fonts and derivatives, however, cannot be released under any other type of license. The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives. DEFINITIONS "Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation. "Reserved Font Name" refers to any names specified as such after the copyright statement(s). "Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s). "Modified Version" refers to any derivative made by adding to, deleting, or substituting -- in part or in whole -- any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment. "Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software. PERMISSION & CONDITIONS Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. 3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users. 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission. 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. TERMINATION This license becomes null and void if any of the above conditions are not met. DISCLAIMER THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. ``` Dernière mise à jour : 12 octobre 2026 *** --- title: "Matisse Chenavas, AI Adoption Lead and engineer" description: "I am Matisse Chenavas, AI Adoption Lead and software engineer: I bring AI and agentic engineering into the real work of teams." url: "https://mc-stud.io/en" lang: "en" updated: "2026-10-12" --- Hi, I’m Matisse Chenavas # I take AI from the pilot to your teams' real work. - AI Adoption Lead - software engineer - founder of MC Studio With you, I pick the right use cases I help teams adopt AI without breaking what works: measurable use cases, protected data, agents that fit their methods, and people trained to use them. I have shipped software for real organisations since 2022, and I work with agents myself every day. [Talk about your project](https://mc-stud.io/en/contact) [See the work](https://mc-stud.io/en/work) ![Portrait of Matisse Chenavas.](https://mc-stud.io/_astro/01-hero-portrait.CTqtA5AW_1wswFE.jpg) Who I am ## An engineer who stays until it is used I learned the trade by shipping. Trained at 42 Lyon, I signed my first developer contract in 2022. Since then I have built systems that serve real users, mostly from inside my clients' teams: an after-sales automation in production in healthcare, a mobile app and its back office, a document-reading benchmark under health-data constraints. In January 2026 I founded MC Studio to carry this work under my own name. My field: operational AI and agentic engineering, where security, traceability and adoption matter as much as the model. I work with agents every day, framed by written rules, skills and verified workflows; this site is built that way. That is the method I bring to the teams I join, and when a project calls for it, I can bring together a small team of hand-picked independents. **First developer contract** 2022 **MC Studio, founded in January** 2026 **Trained at** 42 Lyon **Working languages** FR · EN [My background](https://mc-stud.io/en/about) Landmarks ## A few facts you can check on this site **client organisations, directly or alongside partners** 5 **published case studies, limits included** 9 **projects that integrate AI or train people to use it** 7 **tools published on GitHub for working with agents, 5 of them open source** 6 Every case study and tool counted here can be read on this site. I have shipped software since 2022, and MC Studio has existed since January 2026. Expertise ## What the market asks me for first Operational AI and its adoption by teams come first: that is where projects most often fail, and where I am most useful. The rest of the chain follows, because an agent without reliable data or an application to live in is useless. 1. Flagship role ### [Operational AI](https://mc-stud.io/en/expertise#ai) When AI was tested without a criterion or a frame, and never left the pilot. LLMs, agents, RAG, OCR and vision models, open-weight or self-hosted models: used where they bring measurable value, with clear data boundaries and human validation. 2. Flagship role ### [AI adoption and training](https://mc-stud.io/en/expertise#adoption) When everyone tinkers with their own assistant, with no shared rule or measurement. Taking AI from isolated trials to a team practice: usage rules, guardrails, agentic engineering training for developers, internal champions and usage measurement. 3. ### [Data and automation](https://mc-stud.io/en/expertise#data) When the information exists but never reaches the right place. 4. ### [Custom business applications](https://mc-stud.io/en/expertise#applications) When spreadsheets, email and re-keying stand in for a system. 5. ### [Architecture, environments and hosting](https://mc-stud.io/en/expertise#architecture) When technical debt and hosting slow down every change. [All expertise](https://mc-stud.io/en/expertise) Working inside teams ## I join your team, then I upgrade the way it works I mostly work inside my clients' teams, on projects I did not all start. It gave me a method: join your rituals first, understand what already works, then set up, sized to the team, the agentic work primitives I use every day at MC Studio. 1. ### Rules written for humans and agents An AGENTS.md, one page per project, recorded decisions. The newcomer and the agent read the same source, and it gets reviewed like code. 2. ### Know-how as skills A recurring procedure becomes a skill the agent loads at the right moment. In my own work, preparing the monthly activity report is one, with its verification rules. 3. ### Graph workflows, with human approval Long tasks become graphs of steps, with resumption and human decision points. That is what pi-graph and Zedflow are for, two tools I publish. 4. ### Proof before trust Tests, checks and reviews are part of the flow. An agent that cannot show what it verified is not done. This site is built that way: several agents with assigned files, written instructions, a build and a type check on every pass, and my review before publishing. [See my open-source tools](https://mc-stud.io/en/open-source) Work ## Proof files, not a gallery Each case study reads in one go: the key points in thirty seconds, then the story, the proof and the limits. 1. Healthcare, medical-device distribution 2024-2026 Through a partner AI ### [Automating after-sales returns to manufacturers, with a trace of every request](https://mc-stud.io/en/work/robotform-after-sales-forms) Santécie’s after-sales return files are routed to the right manufacturer forms and filled automatically, with an audit trail for every request. 2. IT services 2026 Direct AI ### [Training developers in agentic engineering, in eight sessions](https://mc-stud.io/en/work/agentic-engineering-training) I am preparing an eight-session path, designed to take developers from occasional use of an assistant to verifiable agentic engineering, including knowing when to do without it; first session on 16 October 2026. 3. AI agent tooling 2026 Internal project AI ### [Zedflow, agent flows you can read, compose and control](https://mc-stud.io/en/work/zedflow-agent-flows) With Zedflow, an agent flow is read, validated and composed like a program, and sensitive decisions wait for a human approval. [All work](https://mc-stud.io/en/work) Clients and tools ## Who I work with, and with what ### Clients and partners - [Santécie](https://santecie.com/) - [Essan NFC](https://www.essannfc.com/) - [Silico](https://silico.fr/) - [Serial Coders](https://serialcoders.fr/) ### Everyday technologies - [TypeScript](https://www.typescriptlang.org/) - [React](https://react.dev/) - [NestJS](https://nestjs.com/) - [Prisma](https://www.prisma.io/) - [PostgreSQL](https://www.postgresql.org/) - [Python](https://www.python.org/) - [Rust](https://www.rust-lang.org/) - [Docker](https://www.docker.com/) - [Coder](https://coder.com/) - [Cloudflare](https://www.cloudflare.com/) - [Railway](https://railway.com/) - [Anthropic / Claude](https://www.anthropic.com/) - [LangChain](https://www.langchain.com/) - [Ollama](https://ollama.com/) - [vLLM](https://vllm.ai/) - [Hugging Face](https://huggingface.co/) - [NVIDIA](https://www.nvidia.com/) - [Astro](https://astro.build/) - [GitHub](https://github.com/) Every logo links to the official site of the organisation or project. Trademarks belong to their owners. For IT firms and agencies ## My expertise, serving your clients Your clients ask you for AI and agents, and your teams already ship a lot. I know subcontracting from the inside: your client stays yours, I bring the skills you lack, and I train your teams so they keep them. [Work together](https://mc-stud.io/en/partners) 1. I do not take your territory 2. I bring what you lack 3. I train your developers Agents and open source ## Tools for engineers who code with agents I publish the tools I build for my own work with agents: an agent-flow engine, extensions for the Pi coding agent, skills, my context configuration. Each with its install command, what it does and when to reach for it. Beta Pi context ### [pi-context-tree](https://mc-stud.io/en/open-source/pi-context-tree) An extension for the Pi coding agent that injects the right context at the right time, by path and operation, from CONTEXT.json files versioned in the repository. **12** commits / 12 months v0.4.2 `ZEDIUM-Off/pi-context-tree` Beta Pi subagents ### [pi-runtime-monitor](https://mc-stud.io/en/open-source/pi-runtime-monitor) A lightweight Pi extension that shows, in the footer, the CPU, memory and aggregated usage of your session’s subagents. **3** commits / 12 months v0.1.1 `ZEDIUM-Off/pi-runtime-monitor` Experimental skills planning ### [plan-writer](https://mc-stud.io/en/open-source/skills) My shared agent skills, installable with the skills CLI; for now plan-⁠writer, which helps write structured implementation plans. **4** commits / 12 months `ZEDIUM-Off/skills` [All tools](https://mc-stud.io/en/open-source) Articles ## Field notes What I learn by shipping and by working with agents: methods, lessons, limits. - October 11, 2026 5 min read AI ### [Joining a team, then upgrading the way it works with agents](https://mc-stud.io/en/articles/joining-a-team-and-installing-agentic-primitives) How I join an existing team and install, sized to it, agentic work primitives: written context, recorded decisions, skills, workflows with human approval, proof before trust. - October 8, 2026 5 min read AI ### [Automating a sensitive process without losing traceability](https://mc-stud.io/en/articles/automating-a-sensitive-process-without-losing-traceability) Automating a process that touches health data, payroll or invoicing is not about speed. It is about memory: knowing, afterwards, who decided what, under which rules and on which data. [All articles](https://mc-stud.io/en/articles) ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "Approach" description: "I start from the business as it really runs, not from technology: I make complexity readable, then build the simplest system that meets the need." url: "https://mc-stud.io/en/approach" lang: "en" updated: "2026-10-12" --- Approach # Clarify to decide, deliver to act I start from the business as it really runs, not from technology. My job is to make complexity readable, then build the simplest system that meets the whole need. Vision ## Augmented work, not replaced work In most organisations, a large share of the working day is spent imitating a machine: looking for a piece of information, copying it, re-keying it, chasing it, consolidating it. None of it calls for judgement, yet it ties up skilled people. Useful technology removes those mechanical gestures and gives teams back what requires discernment: understanding an unusual case, weighing options, advising, looking after a relationship. That is the test I apply to every project. If a system does not free up time for decisions, expertise or relationships, it is not the right one yet. The whole chain ## From vision to measurement, without gaps I hold the thread end to end. The intent does not get lost between whoever scopes, whoever builds and whoever trains. 1. ### Understand The business, the friction, the goals. 2. ### Structure Processes, data, priorities. 3. ### Design Journeys, architecture, options. 4. ### Build A solid, tested, documented system. 5. ### Secure Access, data, compliance. 6. ### Deploy Production release and monitoring. 7. ### Drive adoption Training and support. 8. ### Measure Actual usage and business impact. Method ## Ninety days, five decisions Every stage ends with an explicit decision. You know what has been delivered, what remains uncertain and what you decide next. 1. Day 0 to 10 ### Understand what really happens Interviews with the people doing the work, process observation, an inventory of tools, data and constraints. **Deliverable** Project summary and identified risks **Decision** Does the problem deserve a system? 2. Day 10 to 30 ### Scope and prioritise Compared options, MVP scope, target architecture, budget and success criteria. **Deliverable** MVP scope and costed options **Decision** Which option do we launch? 3. Day 30 to 60 ### Prototype or pilot A first usable system, tried with real users and representative data. **Deliverable** Pilot in real conditions **Decision** Does the pilot deliver? 4. Day 60 to 90 ### Deploy, train, measure Production release, team training, first usage and impact indicators. **Deliverable** System in production and indicators **Decision** Extend, adjust or stop? 5. Afterwards ### Improve and hand over Stabilisation, documentation, skills transfer or maintenance. **Deliverable** Documentation and team autonomy **Decision** Who owns the system tomorrow? Reading guide ## How to read a case study Every case study fits in five lines, from the stake to the limits; the narrative develops each one. The limits are part of the proof. 1. ### Stake What was at stake for the client, in one sentence. 2. ### Mechanism How the system produces that change. 3. ### Proof What demonstrates it: measurements, usage, material available on request. 4. ### Impact What it brings to the business, in time, risk or quality. 5. ### Limits What is not demonstrated, or still needs work. Guardrails ## Governance, security, measurement 1. ### Human validation required Commercial, legal, financial or sensitive decisions stay in human hands. Systems prepare, people decide. 2. ### Security by design Access management, data isolation, reproducible environments and traceability belong to the initial scope, not to a later project. 3. ### Measure before extending Every system ships with its own usage and impact indicators, defined before they are measured. We extend what works and stop what does not. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io) *** --- title: "Expertise" description: "My five areas of expertise, from AI adoption to architecture: each starts from a concrete symptom and ends with a system in use." url: "https://mc-stud.io/en/expertise" lang: "en" updated: "2026-10-12" --- Expertise # From AI adoption to the foundations that carry it Five skills, ordered by what organisations ask me for first. The first two make up the AI Adoption Lead role; the next three are what make it possible. The role I offer AI Adoption Lead Taking AI from isolated trials to measured use: choosing use cases, setting data and access boundaries, defining how results are evaluated, equipping and training teams, then tracking adoption over time. - Measurable pilots, with acceptance criteria - Guardrails: data, access, traceability - Training and a network of internal champions A role I offer on engagements, backed by the projects in my case studies. 1. [01 Operational AI](https://mc-stud.io/en/expertise#ai) 2. [02 AI adoption and training](https://mc-stud.io/en/expertise#adoption) 3. [03 Data and automation](https://mc-stud.io/en/expertise#data) 4. [04 Custom business applications](https://mc-stud.io/en/expertise#applications) 5. [05 Architecture, environments and hosting](https://mc-stud.io/en/expertise#architecture) Flagship role ## Operational AI LLMs, agents, RAG, OCR and vision models, open-weight or self-hosted models: used where they bring measurable value, with clear data boundaries and human validation. The symptom When AI was tested without a criterion or a frame, and never left the pilot. What I deliver - Use cases chosen against a written success criterion - Comparative benchmarks before any model or vendor choice - Bounded assistants and agents, with human validation - Private or local hosting when the data requires it Typical tools - LLM - Agents - RAG - OCR and VLM - Open-weight models - Evaluation Related proof 1. Healthcare, medical-device distribution 2024-2026 Through a partner AI ### [Automating after-sales returns to manufacturers, with a trace of every request](https://mc-stud.io/en/work/robotform-after-sales-forms) Santécie’s after-sales return files are routed to the right manufacturer forms and filled automatically, with an audit trail for every request. 2. IT services 2026 Direct AI ### [Training developers in agentic engineering, in eight sessions](https://mc-stud.io/en/work/agentic-engineering-training) I am preparing an eight-session path, designed to take developers from occasional use of an assistant to verifiable agentic engineering, including knowing when to do without it; first session on 16 October 2026. [See all 6 case studies in the work section](https://mc-stud.io/en/work) Flagship role ## AI adoption and training Taking AI from isolated trials to a team practice: usage rules, guardrails, agentic engineering training for developers, internal champions and usage measurement. The symptom When everyone tinkers with their own assistant, with no shared rule or measurement. What I deliver - Usage frame: allowed data, access, traceability - Agentic engineering programme for developers, on your repositories - Team primitives: AGENTS.md, skills, verified workflows - Adoption indicators defined before rollout Typical tools - Workshops - Hands-on labs - AGENTS.md - Skills - Usage measurement Related proof 1. IT services 2026 Direct AI ### [A controlled development environment, ready for coding with AI](https://mc-stud.io/en/work/coder-developer-environments) Silico’s developers have standardised environments, described as code and hosted on controlled infrastructure, the foundation of a governed use of AI. [See all 2 case studies in the work section](https://mc-stud.io/en/work) ## Data and automation Connect scattered data, automate what should be automated, and keep a trace of every decision the system makes. The symptom When the information exists but never reaches the right place. What I deliver - Map of flows and sources - Routing, processing queues and automations - Run traces and replay without duplicates - Impact indicators defined before they are measured Typical tools - SQL - [Python](https://www.python.org/) - [PostgreSQL](https://www.postgresql.org/) - BullMQ - Windmill - APIs Related proof 1. Healthcare, medical-device distribution 2024-2026 Through a partner AI ### [Automating after-sales returns to manufacturers, with a trace of every request](https://mc-stud.io/en/work/robotform-after-sales-forms) Santécie’s after-sales return files are routed to the right manufacturer forms and filled automatically, with an audit trail for every request. ## Custom business applications Internal tools shaped around your real processes: case handling, forms and approvals, back offices, mobile apps, admin portals. The symptom When spreadsheets, email and re-keying stand in for a system. What I deliver - Process scoping and MVP definition - Journeys designed with field teams - Full-stack development, web and mobile - Production release, documentation and handover Typical tools - [TypeScript](https://www.typescriptlang.org/) - Vue.js - [NestJS](https://nestjs.com/) - [Prisma](https://www.prisma.io/) - React Native - [PostgreSQL](https://www.postgresql.org/) Related proof 1. Sport and coaching 2025-2026 Through a partner AI ### [Turning a training method into a mobile app and its back office](https://mc-stud.io/en/work/nfc-training-mobile-app) The NFC method exists as a product: a mobile app for members and a back office for the team, on a single data foundation. 2. Social protection, paid-leave fund 2024-2025 Through a partner ### [A paid-leave request application for CICP2R](https://mc-stud.io/en/work/cicp-leave-requests) On the employer side, paid-leave requests and days to pay are entered in a dedicated application, then go through an explicit validation. [See all 4 case studies in the work section](https://mc-stud.io/en/work) ## Architecture, environments and hosting Foundations that last: architecture, reproducible developer environments, deployment, maintenance and documentation, with security considered from the start. The symptom When technical debt and hosting slow down every change. What I deliver - Architecture audit and recorded decisions - Developer environments described as code - Integration with your existing information system - Deployment, monitoring and maintenance Typical tools - [Docker](https://www.docker.com/) - Terraform - [Coder](https://coder.com/) - [Railway](https://railway.com/) - [Cloudflare](https://www.cloudflare.com/) - CI/CD Related proof 1. AI agent tooling 2026 Internal project AI ### [Zedflow, agent flows you can read, compose and control](https://mc-stud.io/en/work/zedflow-agent-flows) With Zedflow, an agent flow is read, validated and composed like a program, and sensitive decisions wait for a human approval. 2. Healthcare, supplementary health insurance 2026 Through a partner AI ### [Choosing a health-card reading engine on evidence, not on a demo](https://mc-stud.io/en/work/scie-ocr-health-insurance-cards) The choice of a reading engine for supplementary health insurance cards rests on a reproducible benchmark, not on a sales demo. [See all 5 case studies in the work section](https://mc-stud.io/en/work) ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "Work" description: "My proof dossiers: real projects, delivered directly or inside a partner’s team, with the key points in thirty seconds, then the proof and the limits." url: "https://mc-stud.io/en/work" lang: "en" updated: "2026-10-12" --- Work · 9 case studies # Proof files Real projects, delivered directly or inside a partner’s teams for its end clients. Each case study gives the key points in thirty seconds, then the story, the proof and the limits. Clients - [Santécie](https://santecie.com/) - [Silico](https://silico.fr/) - [Essan NFC](https://www.essannfc.com/) Santécie 2024-2026 AI In production ## [Automating after-sales returns to manufacturers, with a trace of every request](https://mc-stud.io/en/work/robotform-after-sales-forms) Santécie’s after-sales return files are routed to the right manufacturer forms and filled automatically, with an audit trail for every request. **Stake** Every after-sales return must reach the manufacturer on that manufacturer’s own form; copying files across by hand took time and invited costly mistakes. **Impact** Data entry becomes configuration: at least 500 hours avoided per 10,000 requests, and a failed request is replayed without redoing the batch. Through a partner Read the case study Silico 2026 AI In preparation ## [Training developers in agentic engineering, in eight sessions](https://mc-stud.io/en/work/agentic-engineering-training) I am preparing an eight-session path, designed to take developers from occasional use of an assistant to verifiable agentic engineering, including knowing when to do without it; first session on 16 October 2026. Direct Read the case study 2026 AI Pilot ## [Zedflow, agent flows you can read, compose and control](https://mc-stud.io/en/work/zedflow-agent-flows) With Zedflow, an agent flow is read, validated and composed like a program, and sensitive decisions wait for a human approval. Internal project Read the case study Santécie 2026 AI Demonstrator ## [Choosing a health-card reading engine on evidence, not on a demo](https://mc-stud.io/en/work/scie-ocr-health-insurance-cards) The choice of a reading engine for supplementary health insurance cards rests on a reproducible benchmark, not on a sales demo. Through a partner Read the case study Silico 2026 AI ## [A controlled development environment, ready for coding with AI](https://mc-stud.io/en/work/coder-developer-environments) Silico’s developers have standardised environments, described as code and hosted on controlled infrastructure, the foundation of a governed use of AI. Direct Read the case study Essan NFC 2025-2026 AI Paused ## [Turning a training method into a mobile app and its back office](https://mc-stud.io/en/work/nfc-training-mobile-app) The NFC method exists as a product: a mobile app for members and a back office for the team, on a single data foundation. Through a partner Read the case study 2026 AI Demonstrator ## [A memory shared between agents, partitioned by role](https://mc-stud.io/en/work/agent-memory-isolation) Several agents rely on a shared graph memory, and none of them can reach another’s scope. Internal project Read the case study 2024-2025 ## [A paid-leave request application for CICP2R](https://mc-stud.io/en/work/cicp-leave-requests) On the employer side, paid-leave requests and days to pay are entered in a dedicated application, then go through an explicit validation. Through a partner Read the case study 2026 ## [Connecting LumiSafe masts to a software gateway, for railway track safety](https://mc-stud.io/en/work/lumisafe-mast-signalling) LumiSafe masts talk to a software gateway over a serial protocol that evolves without breaking masts still running an earlier version. Through a partner Read the case study Reading guide ## How to read a case study Every case study fits in five lines, from the stake to the limits; the narrative develops each one. The limits are part of the proof. 1. ### Stake What was at stake for the client, in one sentence. 2. ### Mechanism How the system produces that change. 3. ### Proof What demonstrates it: measurements, usage, material available on request. 4. ### Impact What it brings to the business, in time, risk or quality. 5. ### Limits What is not demonstrated, or still needs work. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io) *** --- title: "Articles" description: "My field notes: methods, lessons and limits observed while delivering business systems and working with agents." url: "https://mc-stud.io/en/articles" lang: "en" updated: "2026-10-12" --- Articles # Field notes Methods, lessons and limits observed while delivering business systems and working with agents. October 11, 2026 5 min read Adoption AI ## [Joining a team, then upgrading the way it works with agents](https://mc-stud.io/en/articles/joining-a-team-and-installing-agentic-primitives) How I join an existing team and install, sized to it, agentic work primitives: written context, recorded decisions, skills, workflows with human approval, proof before trust. - I join a team through its rituals and its code, not through my tools. - The first primitives are texts: a context file, recorded decisions, a glossary. Humans and agents read the same source. - A recurring procedure becomes a skill; a long task becomes a graph with human approvals. October 8, 2026 5 min read Data AI ## [Automating a sensitive process without losing traceability](https://mc-stud.io/en/articles/automating-a-sensitive-process-without-losing-traceability) Automating a process that touches health data, payroll or invoicing is not about speed. It is about memory: knowing, afterwards, who decided what, under which rules and on which data. October 1, 2026 5 min read Operational AI AI ## [From idea to pilot: running an AI project you can measure](https://mc-stud.io/en/articles/from-idea-to-pilot-a-measurable-ai-project) Most AI projects do not die from a bad model. They die from a pilot with no success criterion. Here is how I build a pilot that leads to a decision. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io) *** --- title: "Agents and open source" description: "The extensions, skills and tools I build for my own work with coding agents, published as they are: usage, install and source code." url: "https://mc-stud.io/en/open-source" lang: "en" updated: "2026-10-12" --- Agents and open source # Tools for coding with agents The extensions, skills and tools I build for my own work with coding agents, published as they are: what they do, when to reach for them, how to install them. [github.com/ZEDIUM-Off](https://github.com/ZEDIUM-Off) 708 **commits in 12 months** 6 **public repositories** 11 October 2026 **last update** 1 **GitHub star** GitHub figures taken on 12 October 2026. Beta Pi context ## [pi-context-tree](https://mc-stud.io/en/open-source/pi-context-tree) An extension for the Pi coding agent that injects the right context at the right time, by path and operation, from CONTEXT.json files versioned in the repository. **12** commits / 12 months v0.4.2 `ZEDIUM-Off/pi-context-tree` Beta Pi subagents ## [pi-runtime-monitor](https://mc-stud.io/en/open-source/pi-runtime-monitor) A lightweight Pi extension that shows, in the footer, the CPU, memory and aggregated usage of your session’s subagents. **3** commits / 12 months v0.1.1 `ZEDIUM-Off/pi-runtime-monitor` Experimental skills planning ## [plan-writer](https://mc-stud.io/en/open-source/skills) My shared agent skills, installable with the skills CLI; for now plan-⁠writer, which helps write structured implementation plans. **4** commits / 12 months `ZEDIUM-Off/skills` Experimental agent flows Rust ## [Zedflow](https://mc-stud.io/en/open-source/zedflow) A local engine and studio for typed agent flows: every flow is a graph validated before it runs, with controlled context, human approvals and a trace of every turn. **678** commits / 12 months v0.2.0 `ZEDIUM-Off/zedflow` Beta CLI accounting ## [pennylane-cli](https://mc-stud.io/en/open-source/pennylane-cli) An agent-friendly CLI that exposes the Pennylane API v2 as commands with JSON output, plus an escape hatch for raw requests. **2** commits / 12 months v0.1 `ZEDIUM-Off/pennylane-cli` Experimental Pi context ## [.pi](https://mc-stud.io/en/open-source/pi-config) My Pi context configuration, its public part: compact agent norms (responsibility, contracts, execution, tech stacks), injected through pi-⁠context-⁠tree. **9** commits / 12 months v0.1.0 · 1 ★ `ZEDIUM-Off/.pi` ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "IT firms and agencies: my expertise for your clients" description: "For IT firms and agencies: I complement your teams under your lead, for your clients, and I leave the know-how with you when I go." url: "https://mc-stud.io/en/partners" lang: "en" updated: "2026-10-12" --- For IT firms and agencies # My expertise, serving your clients Your clients ask for AI, agents, automation. Your teams already ship a lot. I come in to complement them, under your lead, and I leave the know-how with you when I go. ## What I commit to, and what I will not do 1. ### I do not take your territory Your client stays yours. I work within your contract, your rituals and your contacts, and I do not pitch to your clients. 2. ### I bring what you lack Operational AI, agents, RAG, OCR, local models, agentic engineering for developers: the rare skill that unblocks a project or strengthens a tender response. 3. ### I train your teams Workshops and hands-on sessions on your own repositories, so your developers keep the method after I leave. ## How we can work together - ### Reinforcement on a client project I join the project team for a specific phase: AI scoping, architecture, pilot, production rollout. - ### Pre-sales and scoping I help you qualify an AI need, price an option and write what is promised, without overselling. - ### Training your developers An agentic engineering course: rules written for agents, skills, workflows, verification, data security. ## What I already do in this setting A large share of my projects has run in this setting, with several partners: embedded in a partner’s team or reinforcing it under its lead, for its end clients. - An after-sales automation in production for a medical-device distributor - A mobile app and its back office for a training method - A document-reading benchmark under health-data constraints - The software of safety masts for railway maintenance I also design agentic engineering courses for developers. Each case study names the end client; the engagement setting sits in its fact sheet. [Read the case studies](https://mc-stud.io/en/work) ## A client, a need, a missing skill? Let’s talk about the project and the setting. I will tell you quickly whether I am the right person. [Propose a collaboration](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=IT%20firm%20or%20agency%20collaboration) *** --- title: "About Matisse Chenavas" description: "A software engineer and the founder of MC Studio, I connect a leadership team’s vision to the realities on the ground and help teams adopt AI." url: "https://mc-stud.io/en/about" lang: "en" updated: "2026-10-12" --- About # Matisse Chenavas - AI Adoption Lead - software engineer - founder of MC Studio I connect a leadership team’s vision to the realities on the ground, then build what is missing between the two. These days it is mostly AI: getting it adopted, properly, by teams that already have a lot on their plate. - [LinkedIn](https://www.linkedin.com/in/matisse-chenavas) - [GitHub](https://github.com/ZEDIUM-Off) - [contact@mc-stud.io](mailto:contact@mc-stud.io) ![Portrait of Matisse Chenavas.](https://mc-stud.io/_astro/01-hero-portrait.CTqtA5AW_1wswFE.jpg) Background ## My path 1. 2021 ### A year of computer science at IUT Lyon 1 The starting point, before choosing project-based learning. 2. 2022 to 2025 ### Trained at 42 Lyon The piscine, then the common core: learning from peers and from projects. 3. 2022 ### First developer contract A fixed-term API developer role in October and November: my first paid assignment. 4. Since 2023 ### Independent software and AI engineer Business applications, automation, document reading, developer environments and agentic engineering training, mostly from inside my clients' teams. As a sole trader until 2025, then through MC Studio. 5. 2024 to 2026 ### Founder of HIGHFINITY A first company, from November 2024 to May 2026. 6. Since 2026 ### MC Studio My studio, founded in January 2026 to carry operational AI and agentic engineering under my own name. ## Right now - I am preparing an eight-session programme to train developers in agentic engineering. - I am building Zedflow, an engine for typed agent flows, and I use it for my own operations. - I publish the code of the tools I use to code with agents. How I work ## Inside your team, or a small team around the project Most of my projects ran inside teams I had not assembled, alongside their developers. That is the setting I know best: I join your rituals, bring scoping, architecture and AI, and equip the team with agentic working methods it keeps after I leave. Either way, you have one point of contact who says what is proven, what is not yet, and who answers for what he ships. 1. ### Embedded in your team I join the project team, its tools and its rituals, and ship with it. That has been the setting of most of my engagements since 2023. 2. ### Agentic methods set up in-house Rules written for humans and agents, skills, workflows with human approval, systematic verification: I set up what serves the team, and I train it to use them. 3. ### A small team, if the project needs it For a larger project, I can bring together a few independents chosen for their speciality, with a written scope and deliverables. I set the architecture, review what goes to production and stay your point of contact. Principles ## What guides my work 1. ### Accuracy over effect I prefer a simple, verified solution to an impressive demo. 2. ### Open about limits I say what is demonstrated, what is assumed and what still needs checking. 3. ### Humans in the loop Systems prepare and speed things up. Binding decisions stay human. 4. ### Handover I document decisions and train teams so they stay autonomous. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "Contact" description: "Tell me what is stuck, even roughly. I will get back to you with a first reading and, if it makes sense, a slot to talk." url: "https://mc-stud.io/en/contact" lang: "en" updated: "2026-10-12" --- Contact # Let’s talk about your project Tell me what is stuck, even roughly. I will get back to you with a first reading and, if it makes sense, a slot to talk. ## By email The simplest way to start. A few lines are enough. [contact@mc-stud.io](mailto:contact@mc-stud.io) I read every message myself and reply within two working days. ## Discovery call (30 min) To talk about your project, your constraints and the best next step. By video, no commitment. Slots come straight from my calendar. [Pick a slot](https://calendar.app.google/VQTPrCgNvQSNwdA7A) ## For a useful first conversation - The context: your organisation, the team involved, the tools in place. - The symptom: what takes too long, gets lost or keeps repeating. - The timing: what makes it urgent or important now. Based near Lyon, France, I work on site and remotely, in French and English. **Are you an IT firm or an agency?** I also work for the clients of my partners, without ever taking their place. [See how](https://mc-stud.io/en/partners) - [LinkedIn](https://www.linkedin.com/in/matisse-chenavas) - [GitHub](https://github.com/ZEDIUM-Off) *** --- title: "Training developers in agentic engineering, in eight sessions" description: "I am preparing a training programme for Silico, designed to take developers from occasional use of an assistant to a verifiable agentic engineering practice: context, bounded delegation, verification, security. First session on 16 October 2026." url: "https://mc-stud.io/en/work/agentic-engineering-training" author: "Matisse Chenavas" date: "2026-10-09" lang: "en" ai: "true" --- # Training developers in agentic engineering, in eight sessions > I am preparing an eight-session path, designed to take developers from occasional use of an assistant to verifiable agentic engineering, including knowing when to do without it; first session on 16 October 2026. - **Client**: Silico - **Sector**: IT services - **Period**: 2026 - **My role**: Programme designer and trainer - **Setting**: Direct - **Team**: Solo · 1 person - **Status**: In preparation - **Technologies**: Git, GitHub, Workshops, Hands-on labs, Assessment - **Reading time**: 3 min ## At a glance - **Stake**: Developers already use AI, each in their own way; what is missing is a shared practice that can be taught, checked and explained to management. - **Mechanism**: Eight afternoons, each followed by an autonomous exercise on a fictional running case, from context to bounded delegation and then verification. - **Proof**: Eight rendered decks, a reusable core of seventeen units, and a direction accepted by Silico on 9 October 2026. - **Impact**: The team will have a shared base for governing AI in code, instead of a patchwork of individual practices. - **Limits**: The first session takes place on Friday 16 October 2026: no learning outcome is measured yet. ## Metrics - 8 afternoon sessions, each followed by an exercise - 138 rendered slides, with speaker notes - 17 units in the reusable core ## The starting point In many teams, AI is already there, but everyone uses it in their own way. Some developers doubt agents are reliable, others fear losing what makes their craft, and management does not quite know what happens in the repositories. Neither a ban nor enthusiasm settles the question. ## What I designed Each session alternates presentation and demonstration, then continues with an exercise to do autonomously before the next one. All exercises use the same running case, a fictional company: you can show everything, break everything and fix everything without touching a client's code. The path follows a simple progression: understand a model's limits, give it the relevant context, delegate a bounded task, verify the result independently, diagnose a failure, then design a workflow another developer can take over. Participants also learn to justify when a script or a simpler workflow is enough. > [!TIP] Model-agnostic > Tools change fast. The programme teaches what lasts: writing context, bounding a delegation, verifying evidence. Tools serve as examples, not as the subject. ### Security, beyond compliance Sessions five and six are about security. The message is explicit: a compliance approach is no longer enough when attackers equip themselves with agents too. The sessions separate what is already observed, what is demonstrated in the lab and what remains prospective, so the team prepares without giving in to alarmism. ### A track for leaders Adoption does not only happen in code. A dedicated track covers accountability, organisational change and measuring usage; leaders who attend the technical sessions are assessed on the same criteria as developers. ## What the evidence shows The materials exist and can be reviewed: decks, speaker notes, PDF handouts and exercise briefs, drawn from a core of units each tied to assessment criteria[^core]. The tool that presents them was itself built with agents, following the method it teaches[^tool]. ## What it changes For the team, the point is to replace isolated habits with a shared base that can be reviewed and improved. Developers learn to justify when an agent is useful, and to prove it; management gets a vocabulary and criteria to follow adoption. The programme's direction was accepted on 9 October 2026[^schedule], and the first session takes place on Friday 16 October 2026. I will complete this case with participants' feedback and the first assessment results. ## Limits - This case describes a programme designed and ready to run, not yet a delivered training. - Assessment criteria are defined; no learning outcome is measured. - Cohort size and protected exercise time remain to be set. [^core]: The core has seventeen units with lessons, decks, speaker notes and labs; this edition draws eight sessions from it. [^tool]: A writing and presentation tool for the sessions, built for the occasion with coding agents, under my review. [^schedule]: Eight to ten Friday afternoons had been negotiated; the chosen edition has eight sessions. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/agentic-engineering-training *** --- title: "Zedflow, agent flows you can read, compose and control" description: "My agent flow engine: every flow is a typed graph, validated before it runs, with human approvals checked on typed data and a trace of every turn." url: "https://mc-stud.io/en/work/zedflow-agent-flows" author: "Matisse Chenavas" date: "2026-10-09" lang: "en" ai: "true" --- # Zedflow, agent flows you can read, compose and control > With Zedflow, an agent flow is read, validated and composed like a program, and sensitive decisions wait for a human approval. - **Client**: MC Studio, research and development - **Sector**: AI agent tooling - **Period**: 2026 - **My role**: Designer and sole developer - **Setting**: Internal project - **Team**: Solo · 1 person - **Status**: Pilot - **Technologies**: Rust, TypeScript, Vue.js, ADK-Rust - **Reading time**: 2 min ## At a glance - **Stake**: Handing agents tasks that commit the business requires reading what they will do, controlling what they see and reviewing what they did. - **Mechanism**: A strict graph, validated before it runs, where a context strategy composes what each model receives and every turn is traced. - **Proof**: The engine, its web studio and the zf command-line tool, published on GitHub and used to prepare my monthly invoicing. - **Impact**: An agent becomes auditable: you know what it saw, what it did and where a human decided. - **Limits**: Zedflow is a preview with no external user; part of the execution is designed but not implemented yet. ## The starting point AI agents can chain actions. What is most often missing is the ability to read what they will do before launching them, to control what they see, and to find out afterwards why they acted as they did. Without that, it is hard to hand them anything but tasks without consequences. ## What I built Zedflow is an agent flow engine and studio[^adk]. A flow is a typed graph, checked before it runs: an invalid transition or a badly declared value is refused with a precise diagnostic, instead of failing in the middle of a run. At every turn, a context strategy decides, block by block, what the model receives; state lives in typed stores, not in the prompt. Bridges connect flows to each other, each with its own responsibility, context and tools. Human approvals are steps of the graph, checked on typed data: an agent can prepare an invoice, it cannot send it until the person in charge has approved. > [!NOTE] A software factory, not a single agent > The guiding idea: one specialised flow per responsibility, composed with the others like a production line, with humans approving what matters. ## What the evidence shows The code is public, with the engine, the web studio and the command-line tool[^git]. You can try it locally with a demo provider, without an account or a real model. Every turn can be reviewed in the studio: what the model received, which tools ran, what changed. ## What it changes For a client, this approach makes an agent auditable, and that is the condition for handing it tasks that commit the business. I apply it to myself first: Zedflow prepares my monthly invoicing, and nothing leaves without my approval[^billing]. It is also a testing ground for what I recommend to my clients: useful, bounded agents whose every decision can be reviewed. ## Limits - Formats and interfaces still change, and part of the execution is designed but not implemented yet. - No external user to date; the only real use is internal to MC Studio. - The licence, PolyForm Noncommercial 1.0.0, reserves commercial use for a separate agreement. [^adk]: Zedflow builds on ADK-Rust, whose graph workflows follow the same principles as LangGraph. [^git]: 690 commits, all mine, from 8 July 2026 to 3 October 2026 (default branch of the public repository, as of 12 October 2026). [^billing]: Agents prepare the invoice and email drafts; sending waits for my explicit approval, a step of the graph. ## Links - [GitHub repository](https://github.com/ZEDIUM-Off/zedflow) --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/zedflow-agent-flows *** --- title: "Choosing a health-card reading engine on evidence, not on a demo" description: "For Santécie, a benchmark that compares OCR and VLM engines for reading supplementary health insurance cards, under health-data constraints, with a human check of every field." url: "https://mc-stud.io/en/work/scie-ocr-health-insurance-cards" author: "Matisse Chenavas" date: "2026-10-05" lang: "en" ai: "true" --- # Choosing a health-card reading engine on evidence, not on a demo > The choice of a reading engine for supplementary health insurance cards rests on a reproducible benchmark, not on a sales demo. - **Client**: Santécie - **Sector**: Healthcare, supplementary health insurance - **Period**: 2026 - **My role**: Project owner and architect - **Setting**: Through a partner - **Team**: Solo · 1 person - **Status**: Demonstrator - **Technologies**: Python, NestJS, Docker, TypeScript, Marimo, OCR, VLM - **Reading time**: 3 min ## At a glance - **Stake**: Before handing supplementary health card reading to an engine, Santécie needed to know which one is reliable, and where the data is allowed to go. - **Mechanism**: A shared core drives versioned Python pipelines from NestJS, and every run produces immutable, therefore comparable, artefacts. - **Proof**: Eleven architecture decisions, an analysis of OCR offers under HDS constraints and 206 automated tests, in a repository I am the sole author of. - **Impact**: Santécie can decide between local processing, a hosted open-weight model and an external service on measurements, before committing to a vendor. - **Limits**: It is a demonstrator: no recognition rate is published, and it claims neither production quality nor medical compliance. ## Metrics - 11 recorded architecture decisions - 206 automated tests passing locally ## The starting point Reading a supplementary health insurance card looks simple. In practice, formats vary from one insurer to another, photos are taken in imperfect conditions, and above all the data is health data: where it is processed, by whom and for how long is not an implementation detail[^hds]. The temptation with this kind of subject is to plug in the best-known service and judge it on a few examples. The project takes the opposite stance: first build something to compare with, then choose. ## What I built The target is a tool that reads the card on the workstation and proposes business fields, each optional and editable, which a person checks before any confirmation. To choose the engine that will make it possible, I built the benchmark first. Every pipeline is versioned and produces artefacts that never change again: you compare two engines, or two settings, without ambiguity. I separated control (NestJS) from execution (Python) and isolated inference from the workers, to change models without touching the rest. An annotation tool builds the ground truth, field by field, on specimen cards. > [!TIP] Build something to compare with before choosing > A benchmark looks slow at first. In fact it speeds everything else up: each new option is tested in a few hours, and the discussion is about results, not demos. ## What the evidence shows A large part of the work is written down: the architecture decisions, an analysis of hosted OCR vendors and their confidentiality commitments, notes on open-weight model inference. They let the client understand why an option is kept or dropped, and let a new developer pick the project up without rediscovering everything[^git]. The code is checked by an automated test suite[^tests]. Comparisons are read in notebooks, from the immutable artefacts of each campaign. ## What it changes The question "should the data leave the workstation?" is settled on measurements, not on a sales promise. The target of the next benchmark, on dedicated GPU infrastructure, is decided; its results will feed the choice between local processing, a hosted open-weight model and an external service, with zero retention if an external API is used for the benchmark. ## Limits - No recognition rate is published: the results of the benchmark on dedicated infrastructure are not available yet. - The screenshots show the annotation tool and a comparison notebook on synthetic data, not a finished product. - Real samples stay private and never leave the client's perimeter. - The system does not check entitlements and makes no automated decision. [^hds]: HDS stands for hébergement de données de santé, the certification required in France to host health data on behalf of a third party. It guided the analysis of hosted OCR offers. [^git]: Sole author of the repository: 207 commits, from 14 August to 5 October 2026. [^tests]: 206 tests pass locally as of 7 October 2026. They check the code, not reading quality. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/scie-ocr-health-insurance-cards *** --- title: "Automating after-sales returns to manufacturers, with a trace of every request" description: "For Santécie, a medical-device distributor, a production automation that turns after-sales return files into filled manufacturer forms, with an audit trail for every request." url: "https://mc-stud.io/en/work/robotform-after-sales-forms" author: "Matisse Chenavas" date: "2026-09-18" lang: "en" ai: "true" --- # Automating after-sales returns to manufacturers, with a trace of every request > Santécie’s after-sales return files are routed to the right manufacturer forms and filled automatically, with an audit trail for every request. - **Client**: Santécie - **Sector**: Healthcare, medical-device distribution - **Period**: 2024-2026 - **My role**: Main developer, back end and front end - **Setting**: Through a partner - **Team**: Embedded in an existing team · 2 people (Embedded in the project team, with a second developer in 2024-2025.) - **Status**: In production - **Technologies**: NestJS, Prisma, Vue.js, Pinia, TypeScript, BullMQ - **Reading time**: 4 min ## At a glance - **Stake**: Every after-sales return must reach the manufacturer on that manufacturer’s own form; copying files across by hand took time and invited costly mistakes. - **Mechanism**: Versioned routing rules designate the target forms, deterministic automation fills them, and AI only ever sees synthetic samples. - **Proof**: Tens of thousands of requests processed in production since September 2025, with 100% operational completion according to my operational monitoring. - **Impact**: Data entry becomes configuration: at least 500 hours avoided per 10,000 requests, and a failed request is replayed without redoing the batch. - **Limits**: The indicators come from operational monitoring I report; they have not been independently audited. ## Metrics - tens of thousands of requests processed in production since September 2025 - 100% operational completion, as defined above - 0 operational failures, external outages tracked separately - ≥ 500 h of data entry avoided per 10,000 requests (estimate) ## The starting point Santécie distributes medical devices. When a device comes back for after-sales service, the return must go to the manufacturer with the right form, filled according to that manufacturer's template: each manufacturer has its own fields, versions and requirements. Return files mostly arrive as Excel spreadsheets, and someone had to copy their content across, form after form. That work requires no judgement, but constant attention, and a copying mistake is expensive to fix. So the request had two parts: stop the re-keying, and know afterwards what was sent, where and why. ## What I built The heart of the system is not the filling but the **routing**. A file can concern one form, several, or none, depending on its content. I structured the domain around three sharp notions: the form group, identified by a stable business code; the routing configuration, written as a sequence of conditions; the fill target, which ties a form to a precise version. Two decisions mattered. Routing is resolved at run time, then frozen with the run: you fix a rule without rewriting history, and every filled form keeps the rule that produced it. With the team, I also separated completing a request, which only reruns what failed, from replaying it entirely. A NestJS API with Prisma carries the domain, BullMQ queues absorb the volume, and a Vue 3 interface manages forms, their versions and the rules. Access is split by role, operator or administrator, and logs and processed content have a retention period. ### Where AI goes, and where it does not With health data, the question is not whether AI can help, but where it is allowed to act. Production requests go through deterministic automation, with strict rules and schema. AI-assisted analysis is used only on synthetic samples, to generate the mapping models between incoming columns and a form's fields. Human validation happens upstream, on the configuration, not on each request. > [!IMPORTANT] The data boundary > Production content never goes through a language model. AI speeds up the preparation of mappings; it never sees the real files. ## Working inside the team, not beside it I joined this project the way you join a team: through its code, its vocabulary and its habits, and I became its main author[^git]. Today the repository carries what lets someone else, human or agent, pick it up: a context file at the root, architecture decisions recorded one by one, an audit of the flows and a business glossary shared with the users. That glossary mattered more than it seems. A "request" is not a "batch", a "replay" is not a "completion". The day a user asks why a form was filled twice, the answer lies in those distinctions. ## What the evidence shows The automation has run in production since September 2025. The figures below come from my operational monitoring[^volume], and they only make sense with their definition. > [!NOTE] Defining operational completion > The automation fills the form end to end, without manual rework, and produces an audit trail of the run. This rate says nothing about the semantic correctness of a mapping. External dependency failures are tracked separately, as incidents. The trace can be checked at any time: for a given request, the tool shows which rule applied, which branch was selected and which conditions were evaluated. ## What it changes Re-keying turns into configuration: a rule is set once and applies to every incoming file. At 3 to 5 minutes of manual entry per form, every 10,000 requests represent between 500 and 830 hours of data entry avoided[^estimate]. When a file fails, you know which rule sent it where, and you complete or replay it without redoing the whole batch. The system keeps evolving, with recent work on SAP routing integration and deployment. I work on it as an independent, embedded in the project team: first as a sole trader, then through MC Studio since January 2026. ## Limits - The counts are mine: they have not been independently audited, and the exact volume is available on request. - The completion rate measures end-to-end execution with its trace, not the correctness of each mapping. - Time avoided is an estimate based on a manual entry duration, not a before-and-after measurement. - The project is a team effort: product decisions were shared, and I do not claim sole direction. [^git]: Git history of the repository: 113 of 193 commits are mine, from July 2024 to September 2026. A second developer contributed in 2024 and 2025. A commit count measures neither effort nor quality. [^volume]: Aggregated counts from operational monitoring, which I report. The exact volume and an anonymised export of the counts are available on request. [^estimate]: 10,000 requests × 3 minutes = 500 hours; × 5 minutes = about 830 hours. The 3 to 5 minutes is an estimate of manual filling time, not a measurement. ## Links - [Santécie](https://santecie.com/) --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/robotform-after-sales-forms *** --- title: "Turning a training method into a mobile app and its back office" description: "For Essan NFC, an Expo / React Native app and a MedusaJS back office covering session planning, coaching, nutrition and subscriptions, with an AI coach framed by the method." url: "https://mc-stud.io/en/work/nfc-training-mobile-app" author: "Matisse Chenavas" date: "2026-08-10" lang: "en" ai: "true" --- # Turning a training method into a mobile app and its back office > The NFC method exists as a product: a mobile app for members and a back office for the team, on a single data foundation. - **Client**: Essan NFC - **Sector**: Sport and coaching - **Period**: 2025-2026 - **My role**: Main developer, mobile, back office and AI - **Setting**: Through a partner - **Team**: Embedded in an existing team · 4 people (Embedded in the project team, with at least three other developers.) - **Status**: Paused - **Technologies**: Expo, React, Node.js, Medusa, PostgreSQL, TypeScript, pgvector, pnpm - **Reading time**: 3 min ## At a glance - **Stake**: Essan NFC’s method lived in documents and one-to-one exchanges, so it depended on the availability of the people who carry it. - **Mechanism**: An Expo / React Native app and a MedusaJS back office share one monorepo; the AI coach reads member context but cannot change it. - **Proof**: Main contributor to the repository from September 2025 to August 2026, with an iOS build pipeline validated on a real iPhone. - **Impact**: The method becomes a path the team administers, and the coach answers from the member’s data rather than from generalities. - **Limits**: The project is paused: store release, user numbers and commercial results remain unknown. ## The starting point Essan NFC has a training method: sessions, a progression, nutrition tracking, support from coaches. As long as that method lives in documents and one-to-one exchanges, it cannot follow many members at once. The project was to digitise it without impoverishing it. ## What I built I was the main developer of the app and its back office, embedded in the project team. The MVP scope covers session planning, nutrition, coaching, subscriptions and the profile. The back office, built on MedusaJS, gives the Essan team control over content, users and coaches; PostgreSQL and pgvector hold the data. ### An AI coach that does not answer from memory The AI coach needed the most care. A chat assistant plugged in without a frame quickly produces generic, even risky, advice on a subject that touches health. Here, the model receives the member's context through read-only commands and works in bounded research rounds: it relies on what is known, and cannot change anything. The project also explored running a compact model directly on the phone, for privacy and offline use[^ondevice]. That track stayed a development experiment. > [!NOTE] Exploring is not committing > Testing an on-device model served to learn what could change a decision: size, speed, quality. The product itself stayed on a hosted model. ## What the evidence shows The repository history shows my share of the work[^git], and the AI coach documentation describes its commands and limits. To test on a real iPhone without relying on an online build service, I set up a pipeline that builds and signs the app on a Mac, then installs it on the device[^ios]. ## What it changes The method is no longer carried only by documents and conversations: it becomes a structured path the team administers. The AI coach is designed to rely on the member's data, not on general advice. ## Limits - The project is paused; I will complete this case with its release status and first usage once they are known. - In production, the AI coach relies on a cloud-hosted model. Running on the phone was only an experiment. - Training programmes and nutrition advice are informational and do not replace medical advice. - The screenshots are a web rendering of the mobile app, on a test account: the tab bar does not look exactly as it does natively. [^ondevice]: A Gemma model in GGUF format, loaded with @react-native-ai/llama, reachable only from a development-only debug panel. [^git]: Git history: 222 of 340 commits are mine, from September 2025 to August 2026, alongside at least three other developers. A commit count measures neither effort nor quality. [^ios]: Pipeline validated on 24 July 2026: build and signing on a remote Mac, installation on a physical iPhone. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/nfc-training-mobile-app *** --- title: "A controlled development environment, ready for coding with AI" description: "For Silico, a private registry of development environments described as code, and an AI usage framework for developers: allowed tools, approval gates, indicators defined before any measurement." url: "https://mc-stud.io/en/work/coder-developer-environments" author: "Matisse Chenavas" date: "2026-04-08" lang: "en" ai: "true" --- # A controlled development environment, ready for coding with AI > Silico’s developers have standardised environments, described as code and hosted on controlled infrastructure, the foundation of a governed use of AI. - **Client**: Silico - **Sector**: IT services - **Period**: 2026 - **My role**: Registry designer, contributor to the AI usage framework - **Setting**: Direct - **Team**: Solo · 1 person - **Technologies**: Coder, Docker, Git, Terraform, Devcontainers - **Reading time**: 3 min ## At a glance - **Stake**: Before opening code to AI assistants, an IT services firm must know where they run, which repositories they reach and what trace they leave. - **Mechanism**: Coder templates build on reusable Terraform modules, and written design rules set how to add new ones. - **Proof**: The registry and its documentation, which I wrote alone in one week in early April 2026. - **Impact**: A new workstation or project starts from a shared, versioned base, and the question "where may the assistant work?" gets a technical answer. - **Limits**: Team adoption of the registry is not measured, and no AI-related gain is claimed. ## The starting point In a team that moves from one client project to the next, every developer ends up with their own environment, slightly different from their colleagues'. The gaps stay invisible until the day they cost half a day of troubleshooting. When AI assistants enter daily work, the question gets more serious: which machine does the assistant run on, which repositories can it reach, and what trace is left? A written rule is not enough if the environment does not carry it. ## What I built I designed a private registry of templates for Coder, the tool that creates developers' workspaces. Each template, devcontainer or envbuilder, builds on reusable Terraform modules: the project database, the application environment, Git submodule handling. Written design rules explain how to add a template without duplicating what exists. The structuring choice was to describe environments as code. An environment becomes a versioned, reviewed and reproducible artefact; fixing it once fixes it for everyone. ### A framework for coding with AI On top of that foundation, I contributed to defining practices for a controlled use of AI in development[^iso]: which tools are allowed, which repositories need an extra approval before merge, how to evaluate an assistant on real tasks, a feature, a fix, a refactor, before adopting it. ## What the evidence shows The registry and its design rules are the direct evidence of this work[^git]. For the AI usage framework, the evidence is of another kind: indicators defined with their method, ready to be collected[^baseline]. > [!NOTE] Indicators defined before they are measured > Code review throughput, post-merge defect rate, test coverage, review cost: each indicator has its measurement method and a baseline to collect before rollout. I claim no gain until that measurement exists. ## What it changes A new workstation or project starts from a shared, versioned base; gaps between environments shrink by construction. For AI adoption, the environment the assistant works in becomes something you can review and control. My takeaway: the safety of AI use in code is decided upstream, in that environment. It is a short piece of work, but it conditions what follows: developers' trust, management's trust, and the ability to measure. ## Limits - The number of developers and projects using the registry is not measured to date. - The framework's indicators are defined but not yet measured: no before-and-after gain is claimed. - The framework is part of an alignment effort with ISO/IEC 27001; it is not a certification. [^iso]: Within Silico's governance effort, aligned with ISO/IEC 27001. The registry itself contains nothing specific to the standard. [^git]: Sole author of the registry: 18 commits, from 1 to 8 April 2026. [^baseline]: Baselines are collected during a discovery phase, and targets are set with the engineering and security leads. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/coder-developer-environments *** --- title: "Connecting LumiSafe masts to a software gateway, for railway track safety" description: "For Cesatec, a Python gateway and the firmware of the LumiSafe masts, a patented safety system for railway maintenance, linked by a serial protocol designed to stay compatible from one version to the next." url: "https://mc-stud.io/en/work/lumisafe-mast-signalling" author: "Matisse Chenavas" date: "2026-04-08" lang: "en" --- # Connecting LumiSafe masts to a software gateway, for railway track safety > LumiSafe masts talk to a software gateway over a serial protocol that evolves without breaking masts still running an earlier version. - **Client**: Cesatec - **Sector**: Railway safety, track maintenance - **Period**: 2026 - **My role**: Designer and sole developer of the gateway and the firmware - **Setting**: Through a partner - **Team**: Solo · 1 person - **Technologies**: Python, Arduino, UART - **Reading time**: 2 min ## At a glance - **Stake**: On a track under maintenance, everyone must know in real time whether an agent protects it, including the team leader, remotely. - **Mechanism**: A Python gateway, Hermes, talks to the masts' Arduino firmware over UART; the protocol carries a lock mode and team assignment. - **Proof**: The code and documentation of the gateway and the firmware, which I wrote alone between February and April 2026. - **Impact**: Each mast’s state becomes readable by software, which serves remote supervision, and the protocol grows without updating every mast at once. - **Limits**: Field deployment and its results are not documented here: this case describes the software, not its operation. ## The starting point LumiSafe is Cesatec's patented system for the safety of railway maintenance agents[^product]. On the track, light masts receive the agents' badges, and agents signal their presence that way. The colour code reads from afar: green, the track is not protected; orange, protection is requested, type 1, 2 or 3; red, the track is protected by an agent. Team leaders follow these states remotely, in real time. For that information to flow, each mast must talk reliably to software, and that dialogue must be able to evolve without immobilising the hardware already installed. ## What I built I developed both ends of the chain: Hermes, a Python gateway, and the masts' Arduino firmware, linked by a serial protocol over UART. The protocol carries a lock mode, the fields that assign a mast to a team, and a mast variant with an OLED screen. One rule guides everything else: evolve the protocol without breaking compatibility with earlier versions[^compat]. A mast that has not been updated must keep working with a newer gateway. > [!TIP] Design a hardware protocol like a public API > Once devices are in service, you never update them all on the same day. Adding fields without changing the meaning of the old ones takes a little discipline, and saves synchronising a whole fleet. ## What the evidence shows The work lives in two repositories, the gateway and the firmware, with their documentation and project rules[^git]. There is no screenshot: this work has no interface to show, only a protocol and two programs that speak it. ## What it changes Each mast's state, an agent's presence, the protection requested or granted, becomes data that software can read and pass on, which makes remote follow-up by team leaders possible. The protocol can grow without forcing every mast to update at once. ## Limits - I designed neither the LumiSafe system nor its patent: my scope is the gateway and the firmware. - No field indicator is available: number of masts, worksites, incidents avoided. - This case publishes neither the protocol nor the code, which belong to the engagement. [^product]: Product description based on the LumiSafe page of Cesatec's website, linked in the project facts. [^compat]: Project rule written in the repositories: prefer backward-compatible protocol changes. [^git]: Sole author of both repositories: 11 commits on the gateway, from February to April 2026, and 3 on the firmware, in February 2026. ## Links - [LumiSafe, on Cesatec’s website](https://cesatec.fr/marques/lumisafe/) --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/lumisafe-mast-signalling *** --- title: "A memory shared between agents, partitioned by role" description: "On a fork of the open-source OpenClaw project, a graph memory for agents, hosted on Memgraph, where each agent only reads and writes within its own scope." url: "https://mc-stud.io/en/work/agent-memory-isolation" author: "Matisse Chenavas" date: "2026-02-08" lang: "en" ai: "true" --- # A memory shared between agents, partitioned by role > Several agents rely on a shared graph memory, and none of them can reach another’s scope. - **Client**: MC Studio, research and development - **Sector**: AI agents, knowledge management - **Period**: 2026 - **My role**: Designer and sole developer of the feature - **Setting**: Internal project - **Team**: Solo · 1 person - **Status**: Demonstrator - **Technologies**: TypeScript, Docker, Memgraph, Cypher, Vitest - **Reading time**: 3 min ## At a glance - **Stake**: Agents sharing a memory must not read what another scope entrusted to theirs, and a prompt instruction cannot prevent it. - **Mechanism**: The application checks each actor’s scope before any Cypher query, and the Memgraph database enforces distinct roles from initialisation. - **Proof**: The public code of the session-ux branch: access rules, unit tests and end-to-end tests against a real Memgraph database. - **Impact**: Shared knowledge that does not leak from one scope to another: the starting condition for agents that remember. - **Limits**: Isolation is per agent; per-client scopes and offensive tests remain to be done. ## The starting point As soon as several agents work together, they need memory: what was decided, what was learned, what remains to be done. A shared memory immediately raises another question. If an agent works for a person, a team or a client, it must not be able to read what the others entrusted to theirs. Asking the model "not to look" is not enough. ## What I built On a fork of OpenClaw, an open-source agent project[^fork], I added a graph memory hosted on Memgraph, run in a container. Each actor gets a scope: an agent reads and writes in its own, the operator has an administration scope. Before every query, the application checks that the requested scope is the actor's own, and refuses otherwise. The database applies the same logic on its side: distinct roles for administration, agents and teams, created at initialisation with their own users. If a query slipped past the first check by mistake, it would hit the second. Agents and administrators each have a skill that describes how to use the memory. > [!IMPORTANT] Isolation is not delegated to the prompt > A model can be talked into ignoring an instruction. An access rule in the code and in the database cannot be negotiated. ## What the evidence shows The access rules are covered by unit tests: an agent reaches its own scope and is refused another's. End-to-end tests run against a real Memgraph database, to check that the whole holds up outside mocks[^tests]. The code is public and can be read on the branch[^deck]. ## What it changes For an organisation that wants agents able to remember, this is the starting condition: shared knowledge that does not leak from one scope to another. The same logic, extended to clients or engagements, would keep an agent from using in one file what it learned in another. That is the direction I propose when an organisation wants agents that remember, without mixing files. ## Limits It is a personal demonstrator: it establishes the mechanism, with no external user, and I claim only what the code shows. - Extending it to per-client or per-engagement scopes is a direction, not a delivery. - Offensive security tests, prompt injection and cross-scope exfiltration attempts, are planned but not done yet. - It is a fork branch, not offered to the upstream project. [^fork]: OpenClaw is a third-party open-source project. Only the partitioned memory feature of this branch is mine, developed alone in February 2026. [^tests]: Vitest unit tests on the access rules; end-to-end tests launched by a dedicated script and configuration, against Memgraph in a container. [^deck]: My presentation of this work also mentions audit logs and answers that cite their sources. I have not checked them in the branch yet, so I do not claim them here. ## Links - [session-ux branch of the fork](https://github.com/ZEDIUM-Off/openclaw/tree/session-ux) --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/agent-memory-isolation *** --- title: "A paid-leave request application for CICP2R" description: "For CICP2R, a paid-leave fund, a web application where paid-leave requests and days to pay are entered on the employer side, then validated and passed on." url: "https://mc-stud.io/en/work/cicp-leave-requests" author: "Matisse Chenavas" date: "2025-11-19" lang: "en" --- # A paid-leave request application for CICP2R > On the employer side, paid-leave requests and days to pay are entered in a dedicated application, then go through an explicit validation. - **Client**: CICP2R - **Sector**: Social protection, paid-leave fund - **Period**: 2024-2025 - **My role**: Full-stack developer, contributor - **Setting**: Through a partner - **Team**: Embedded in an existing team · 5 people (Within a team of at least five developers.) - **Technologies**: NestJS, Vue.js, Pinia, TypeScript - **Reading time**: 2 min ## At a glance - **Stake**: A paid-leave fund pays employees' leave indemnities: every request must reach it complete, quantified and validated, without re-keying. - **Mechanism**: A NestJS API structures leave periods and exchanges files with the existing system over SMB; a Vue 3 interface guides data entry. - **Proof**: A year of contributions to the API and the interface, from November 2024 to November 2025, and an audit of the application in October 2025. - **Impact**: Every request has an identifiable status and path, and the application fits into the existing file exchanges instead of duplicating them. - **Limits**: I contributed within a team of at least five developers; I claim neither the lead nor the overall design. ## The starting point CICP2R is a paid-leave fund (caisse de congés payés): a non-profit association founded by employers in 1937, supervised by the French Ministry of Labour, which pays employees their paid-leave indemnities. To pay correctly, it needs every request with its periods, its days to pay and, where relevant, the employee's departure. Leave management gathers many small frictions: a request sent through one channel, validated through another, then copied by hand. Each step is simple; chaining them is much less so. ## What I built I worked on the API as well as the interface, within the project team. The application collects requests, structures leave periods and stores them with each request, then puts them through a validation before export. On the server side, the NestJS API exchanges files with the existing system over SMB: the application fits into the circuit already in place instead of creating a second one. On the interface side, Vue 3 and Pinia carry data entry, the request grid and the leave state. ## What the evidence shows My work shows in the history of both repositories, the API and the interface, over a year[^git]. In October 2025, an audit of the application documented how it actually works[^audit]: storage of leave periods, validation circuit, state management in the interface. The screenshots below come from a local instance of the application, fed with fictional data. ## What it changes Every request has an identifiable status and path, from entry to export. The file exchange with the existing system avoids double entry between the application and the fund. My takeaway: an HR tool is only useful if it matches the organisation's real circuit. The technology matters less than getting that circuit right and the quality of the exchanges with the system that pays. ## Limits - My part is that of a contributor: other developers wrote a large share of the interface. - No usage indicator is available: request volume, number of employers, lead times. - The exact target of the SMB exchange and the go-live date remain to be confirmed. - The project documents contain personal data: nothing from them is reused here, and the screenshots use fictional data. [^git]: Git history: 33 commits on the API and 60 on the interface, from November 2024 to November 2025. A commit count measures neither effort nor quality. [^audit]: Audit notes from October 2025: leave periods stored as JSON, validation circuit, a Pinia store dedicated to leave. They are not published because they quote personal data. ## Links - [CICP2R](https://www.cicp2r.org/) --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/work/cicp-leave-requests *** --- title: "Joining a team, then upgrading the way it works with agents" description: "How I join an existing team and install, sized to it, agentic work primitives: written context, recorded decisions, skills, workflows with human approval, proof before trust." url: "https://mc-stud.io/en/articles/joining-a-team-and-installing-agentic-primitives" author: "Matisse Chenavas" date: "2026-10-11" lang: "en" ai: "true" --- # Joining a team, then upgrading the way it works with agents > How I join an existing team and install, sized to it, agentic work primitives: written context, recorded decisions, skills, workflows with human approval, proof before trust. 5 min read ## Key points - I join a team through its rituals and its code, not through my tools. - The first primitives are texts: a context file, recorded decisions, a glossary. Humans and agents read the same source. - A recurring procedure becomes a skill; a long task becomes a graph with human approvals. - Nothing is done without proof: tests, checks, review. - This site was built that way, by several agents with assigned files, and reviewed by me before publication. Most of my engagements start the same way: a team already exists, with its code, its habits, its rituals and its blind spots. I never arrive on blank ground, and that is a good thing. A team that ships always has good reasons for doing what it does, even when it has never written them down. My job is not to replace that way of working with mine. It is to add, sized to the team, what I call agentic work primitives: simple pieces that both humans and agents know how to use, and that stay when I leave. Here is how I go about it, with examples from real projects and from my own workshop. ## First, listen to the repository In the first weeks I read more than I write. The Git history, the tickets, the implicit conventions, how a review goes, what scares the team when it deploys. I ask a lot of questions, often naive ones, because they are the questions an agent would ask if it could. What I understand, I write down. Not in a report nobody will read, but in a short file at the root of the repository that the team reviews like code: what the project is for, how it is organised, what must not break, where to find the rest. It is the first primitive and the most profitable one. A newcomer saves a week. An agent gets the difference between a plausible change and a correct one. > [!TIP] One text for humans and agents > If a rule only lives in a prompt, only the agent knows it. If it only lives in a developer's head, the agent ignores it. Written in the repository, it serves both and gets fixed in review. ## Write down what the team already knows The second primitive is the recorded decision. On the after-sales automation I contribute to for Santécie, the repository now carries architecture decisions written one by one, an audit of the flows and a business glossary shared with the users. On the health-insurance card reading benchmark, eleven architecture decisions explain why each option was kept or dropped. These documents are not bureaucracy. They are what lets you answer, six months later, "why does the system do that?". And they are what an agent reads before proposing a change, instead of guessing. In my own workspace I push the logic further: every folder has an instruction file for agents, every project its own page, durable context lives in `docs/` and temporary state in a separate folder. An agent knows where it is, what applies here and where to write what it finds. I do not impose that as is on a team; I install the version that serves it. ## Turn procedures into skills Every team has recurring procedures: preparing a release, reviewing a migration, writing a report. When a procedure comes back often enough and has clear verification rules, it becomes a skill: written know-how the agent loads at the right moment, with its steps and its checks. In my own work, preparing my monthly activity report is one. The agent rebuilds the activity from the Git history and my work sessions, separates projects, checks that every day is covered, then drafts the invoice and the email. It never sends them: it shows them to me. The right skill is not the most ambitious one. It is the one that takes away a task the team does without pleasure, while keeping the points where its judgement matters. ## Move from conversations to workflows A conversation with an agent is enough for a short task. For a long one it gets fragile: the context runs out, a step is forgotten, nobody knows where things stand. So I describe the work as a graph of steps, with explicit state, possible resumption and human approvals where things commit the company. That is what two tools I publish are for, pi-graph and Zedflow. In Zedflow, a human approval is a step of the graph, checked on typed data: the amount, the recipient, the period. Not on a "looks fine". ## Proof before trust An agent that says "done" has proved nothing. So I build verification into the workflow: a build and a type check after every pass, tests that fail before they are fixed, a human review before publication. An agent that cannot show what it verified is not done. That holds when an agent gets stuck, too. While this site was being built, an agent tasked with generating images hit a limit of its sandbox. It stopped, described the error and proposed two ways to unblock it, instead of switching off the protection on its own. That is exactly the behaviour I want to install: fail clearly rather than succeed in appearance. ## What it looks like on a real project: this site This site was built by several agents, each with an assigned set of files: one for page structure, one for the reading experience, a third for content. They handed each other written contracts: what each had delivered, what it had not touched, what remained open. Every pass ended with a build and a type check. Not everything went smoothly. A content agent was stopped midway; the next one had to review its partial edits one by one instead of trusting them. That kind of incident is exactly what primitives are for: the state was written down, so were the rules, and resuming was a review, not an investigation. ## What I do not install I do not show up with a stack of tools to adopt wholesale. I do not put an agent on production data without a written boundary. I do not promise productivity gains before measuring them. And I do not ask a team to give up what makes it proud of its craft: agents take the mechanical moves, developers keep the judgement. ## Where to start If you want to try it in your team, three moves are enough to begin: 1. **Write the context file** for your main repository, one page, and review it as a team. 2. **Pick a procedure** that comes back every week, write it as a skill with its checks, and hand it to an agent under supervision. 3. **Set a proof rule**: no agent change is accepted without the build, the tests and a human review. The rest comes with use. And if you want to do it together, that is precisely the work I offer. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/articles/joining-a-team-and-installing-agentic-primitives *** --- title: "Automating a sensitive process without losing traceability" description: "Automating a process that touches health data, payroll or invoicing is not about speed. It is about memory: knowing, afterwards, who decided what, under which rules and on which data." url: "https://mc-stud.io/en/articles/automating-a-sensitive-process-without-losing-traceability" author: "Matisse Chenavas" date: "2026-10-08" lang: "en" ai: "true" --- # Automating a sensitive process without losing traceability > Automating a process that touches health data, payroll or invoicing is not about speed. It is about memory: knowing, afterwards, who decided what, under which rules and on which data. 5 min read ## Key points - For a sensitive process, the right measure is not time saved but the ability to explain every decision six months later. - Resolve the rule at run time, then freeze it with the run: fix tomorrow without rewriting yesterday. - A shared glossary costs a few hours and saves many at every incident. - The system prepares, a person approves: human approval is a step checked on precise data. - Every step must be replayable on its own, without duplicates. When we automate a process, we think about time saved first. That is fair: nobody misses the hours spent copying forms or reformatting spreadsheets. But for a sensitive process, one that handles health data, payroll or invoicing, time saved is the wrong measure of success. The right measure is whether you can answer a simple question six months later: **why did the system do that?** A manual process has an underrated advantage: it leaves human traces. An email, initials on a document, a colleague's memory. Those traces are imperfect, but they exist. A poorly designed automation erases them and replaces them with a black box that acts fast and remembers nothing. That is where team distrust and unexplainable incidents come from. Here is what I have learned designing systems that automate this kind of process, in particular filling after-sales forms from incoming files, and reading supplementary health insurance cards. ## Separate the rule from its execution The first mistake is to confuse a rule with its application. In a routing system, for instance, an incoming record has to be sent to one or more forms depending on its content. The temptation is to compute the destination once, on arrival, and never look at it again. The problem shows up with the first rule change. If the destination is computed on arrival, every pending record keeps the old logic. If it is recomputed continuously, you no longer know which rule actually produced a form that has already been filled. The approach taken on the after-sales routing project for Santécie rests on two principles. First, **the destination is resolved at execution time**, with the rules in force at that moment. Second, **that resolution is frozen with the execution**: every filled form keeps a record of the rule, and the version of the rule, that produced it. You can fix a rule tomorrow without rewriting yesterday's history. This decoupling has a cost: rules must be versioned, and a forecast shown on screen is not authoritative. I explicitly separated the routing "projection", a forecast useful for browsing, from the actual "assignment", computed just before filling. That distinction in vocabulary saved many misunderstandings with users. ## Name things before you automate them Traceability starts with vocabulary. If the business team and the technical team do not use the same words for the same things, no history will ever be readable. On that project, I kept a shared glossary with the team, with a short definition for every term and the words to avoid. A "request" is not a "batch", an "execution" is not a "file", a "replay" is not a "completion". These distinctions look pedantic. They become essential the day a user asks why a form was filled twice: the answer depends precisely on the difference between replaying a whole request and completing only what had failed. I recommend such a glossary to any organisation automating a sensitive process. It costs a few hours at the start and saves many more at every incident. ## Keep people where they bring judgement Automating does not mean automating everything. In a sensitive process, some decisions must stay human, because they commit the organisation or because the machine makes mistakes it cannot detect. The health insurance card reading demonstrator I designed for Santécie is a good example. The system extracts the text from a card and proposes business fields. But every field stays optional and editable, and **a person reviews before anything is confirmed**. The system does not check entitlements and makes no automated decision. It prepares; a person validates. The same principle applies to my own operations. When agents prepare my monthly invoicing, they draft the invoice and the email, but nothing is sent without my explicit approval. Human validation is not a formality tacked on at the end: it is a step of the process, checked against specific data, such as the amount, the recipient or the period, rather than a general impression. So the question is not "what can we automate?" but "where does human judgement add something a rule cannot capture?". That is where the approval points belong. ## Keep data where it should stay Traceability also covers the path the data takes. In a process that handles health data, knowing where it travels matters as much as knowing what the system does with it. On the card reading project, processing is designed to stay on the user's machine. An external service is only considered for benchmarking, and only with a zero data retention guarantee. Real samples never leave the client's environment. That discipline has a price: some services, easier to plug in, are ruled out from the start. But it gives a clear answer to the question a compliance officer will ask sooner or later. ## Make every step replayable An automated process will eventually fail. A malformed file, a service outage, an incomplete rule. The goal is not to avoid every failure but to recover cleanly. That requires every step to be identifiable and replayable on its own. If a record is routed to three forms and one fails, you should be able to rerun that one form, without redoing the other two and without creating duplicates. On the OCR benchmark, every pipeline version produces immutable artefacts: two runs can be compared without wondering whether something changed in between. This is not technical polish. It is what lets a team fix an incident in a few steps, instead of redoing everything by hand and losing trust in the tool along the way. ## Write down decisions, not just code One last, often neglected point: architecture decisions should be written down. Not in a fifty-page document nobody reads, but in short notes, one per decision, stating what was chosen, why, and which options were set aside. On the card reading project, eleven such decisions were recorded: the split between control and execution, immutable artefacts, the conditions for using an external API, the deployment target. The day an auditor, a new developer or the client asks why the system works this way, the answer already exists. ## Where to start If you are considering automating a sensitive process, here are three questions to ask before writing a single line of code: 1. **What will you need to explain in six months?** List the questions an auditor, a client or a colleague might ask. The system must be able to answer them. 2. **Where is human judgement irreplaceable?** Put your approval points there, and make them proper steps of the process. 3. **What happens when a step fails?** If the answer is "we start over", the system is not ready. Useful automation does not take people out of the process. It takes the mechanical gestures off their hands, and leaves them, with a better memory, what calls for discernment. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/articles/automating-a-sensitive-process-without-losing-traceability *** --- title: "From idea to pilot: running an AI project you can measure" description: "Most AI projects do not die from a bad model. They die from a pilot with no success criterion. Here is how I build a pilot that leads to a decision." url: "https://mc-stud.io/en/articles/from-idea-to-pilot-a-measurable-ai-project" author: "Matisse Chenavas" date: "2026-10-01" lang: "en" ai: "true" --- # From idea to pilot: running an AI project you can measure > Most AI projects do not die from a bad model. They die from a pilot with no success criterion. Here is how I build a pilot that leads to a decision. 5 min read ## Key points - A useful pilot ends with a decision: extend, adjust or stop, on criteria written at the start. - Build the means to compare before choosing a model or a vendor. - Confidentiality is a design constraint, not a detail settled after the pilot. - Bound the model: controlled context, read-only access, explicit scope. - Every human correction is a measurement; limits are written as clearly as results. Many organisations have already "tried AI". An assistant connected to a few documents, a convincing demo in a meeting, then nothing. The pilot did not fail, strictly speaking. It simply never led to a decision. That is the symptom I come across most often: an AI project started from a technology rather than from a question. People ask what a language model could do, instead of asking which problem deserves solving, and how they will know it is solved. Here is the approach I follow, shaped by concrete projects: a benchmark for reading supplementary health insurance cards, a conversational coach built into a training app, and agents that prepare part of my own operations. ## Start from the decision, not the model A useful pilot ends with a decision: extend, adjust or stop. If nobody knows at the outset which criteria that decision will rest on, the pilot will produce an impression, not an answer. So before choosing a model, I write down three things with the client. The **precise task** the system must perform, in business terms: read this field on this document, answer this category of question. The **success criterion**, measurable on real cases: a share of correct fields, a processing time, a share of acceptable answers. And the **stop condition**: what, if observed, means the approach does not fit. The last one is the hardest to write, and the most useful. A pilot that cannot fail cannot demonstrate anything. ## Build the means to compare before you choose The second trap is choosing a tool before having a way to judge it. For a task like document reading, there are dozens of options: hosted OCR services, general-purpose vision models, open-weight models you can run yourself. Each has its strengths, costs and confidentiality constraints. For Santécie, rather than plugging in the best-known service and judging it on a few examples, I first built a benchmark. Every pipeline is versioned and produces artefacts that never change. Two engines, or two settings of the same engine, can be compared on the same images without wondering whether something shifted between runs. This work looks slow at first. In practice it speeds up everything else: each new option can be tested in hours, and the discussion is about results, not sales promises. ## Treat confidentiality as a design constraint With sensitive data, "where is the data processed?" is not a detail to settle after the pilot. It determines which options exist at all. For the health insurance cards, processing is designed to stay on the user's machine. An external API is only considered for benchmarking, and only with a zero-retention guarantee. Part of the work was analysing OCR services hosted under French health-data hosting (HDS) rules, their confidentiality commitments, and the conditions under which an open-weight model could be served on controlled infrastructure. That framing rules some solutions out from the start. That is exactly the point: the pilot will not end on an option that compliance rejects afterwards. ## Bound what the model can do A language model plugged in without limits quickly produces answers that sound right and are wrong. On subjects close to health or money, that is not acceptable. In the training app built for Essan NFC, the conversational coach does not answer "from memory". It retrieves the user's context through read-only commands, works in bounded search rounds, and cannot change anything. It relies on what is known about the user and the method, not on generalities. Its advice also stays informational: it does not replace medical advice, and the app says so. The project also explored running a compact model directly on the phone, for privacy and offline use. That track stayed a development experiment: it measured the real constraints (size, speed, quality) without forcing them on the product. That is exactly what exploration is for: learning something that could change a decision, without turning into an implicit commitment. ## Put human validation inside the process An AI pilot that works immediately raises another question: who is responsible for what the system produces? My answer does not change: **the system prepares, a person validates**. On the card reading demonstrator, every proposed field is reviewed by a person before confirmation. In my own operations, agents draft invoices and emails, but nothing goes out without my approval. That validation is not a button added at the end: it is a step of the process, designed from the start and checked against specific data. This choice has a welcome side effect on measurement. Every human correction is a data point: it shows where the system gets things wrong, and how often. The pilot thus produces, as it runs, the indicators needed to decide whether to extend it. ## Write the limits as clearly as the results The last point is about honesty, and credibility. A pilot produces partial results. Presenting them as final sets up disappointment. So every pilot summary I write has a section on limits: what was not tested, the cases where the system fails, the assumptions still to verify. On the OCR benchmark, for instance, the documentation states plainly that it is a demonstrator, with no claim to production quality or medical compliance. That transparency does not weaken the project. It lets the client decide with full knowledge. ## The approach in short 1. **State the decision** the pilot must enable, with a success criterion and a stop condition. 2. **Build the means to compare** before choosing a model or a vendor. 3. **Set the confidentiality frame** from the start, so you do not explore unusable options. 4. **Bound the model**: controlled context, read-only access, explicit scope. 5. **Build human validation in** as a step of the process, and use it as a source of measurement. 6. **Document the limits** as carefully as the results. A measurable AI project is not slower than any other. It simply avoids running the same inconclusive pilot again six months later. --- Matisse Chenavas, Founder of MC Studio. https://mc-stud.io/en/articles/from-idea-to-pilot-a-measurable-ai-project *** --- title: "pennylane-cli, a Pennylane CLI for agents" description: "An agent-friendly CLI that exposes the Pennylane API v2 as commands with JSON output, plus an escape hatch for raw requests." url: "https://mc-stud.io/en/open-source/pennylane-cli" lang: "en" updated: "2026-10-12" --- Beta CLI accounting Pennylane agents # pennylane-cli An agent-friendly CLI that exposes the Pennylane API v2 as commands with JSON output, plus an escape hatch for raw requests. Install `git clone https://github.com/ZEDIUM-Off/pennylane-cli && cd pennylane-cli && pip install -e .` Young tools: read the repository README before installing. **2** commits / 12 months **Latest version** v0.1 **stars** 0 **forks** 0 **contributor** 1 **open issues** 0 **Last commit** 11 October 2026 Commits per month. Last 12 months, each repository on its own scale. GitHub figures taken on 12 October 2026. **Source code** [github.com/ZEDIUM-Off/pennylane-cli](https://github.com/ZEDIUM-Off/pennylane-cli) **Licence** MIT licence **Status** Beta ## What it does pennylane-cli exposes the operations of the Pennylane Company API v2 as command-line commands, with JSON output an agent reads without ambiguity. The 160 visible operations of the OpenAPI specification are covered, and a raw request command is the escape hatch for the rest. I built it for my own operations, where agents prepare invoice drafts that I approve before anything is sent. The CLI installs from a local clone of the repository. [Source code](https://github.com/ZEDIUM-Off/pennylane-cli) ## When to reach for it - An agent needs to read or prepare accounting data in Pennylane. - You want predictable commands with JSON output rather than an improvised HTTP call. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: ".pi, my context configuration for Pi" description: "My Pi context configuration, its public part: compact agent norms (responsibility, contracts, execution, tech stacks), injected through pi-⁠context-⁠tree." url: "https://mc-stud.io/en/open-source/pi-config" lang: "en" updated: "2026-10-12" --- Experimental Pi context norms configuration # .pi My Pi context configuration, its public part: compact agent norms (responsibility, contracts, execution, tech stacks), injected through pi-⁠context-⁠tree. Install `git clone https://github.com/ZEDIUM-Off/.pi.git ~/pi-config` Young tools: read the repository README before installing. **9** commits / 12 months **Latest version** v0.1.0 **star** 1 **forks** 0 **contributor** 1 **open issues** 0 **Last commit** 11 October 2026 Commits per month. Last 12 months, each repository on its own scale. GitHub figures taken on 12 October 2026. **Source code** [github.com/ZEDIUM-Off/.pi](https://github.com/ZEDIUM-Off/.pi) **Licence** MIT licence **Status** Experimental ## What it does This repository publishes the shareable part of my Pi configuration. It holds a `CONTEXT.json` and a set of compact norms: general principles, responsibility, contracts, agent behaviour, execution flow, and rules per tech stack (TypeScript, web, systems). pi-context-tree injects them at the right time. It is public by default, with an allowlist of publishable files; no credentials are synced. Clone it separately to take inspiration, rather than over an existing setup: the README covers both cases. [Source code](https://github.com/ZEDIUM-Off/.pi) ## When to reach for it - You want a concrete example of short, versioned agent norms. - You want to structure deterministic, auditable context in your own setup. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "pi-context-tree, path-based context for Pi" description: "An extension for the Pi coding agent that injects the right context at the right time, by path and operation, from versioned CONTEXT.json files." url: "https://mc-stud.io/en/open-source/pi-context-tree" lang: "en" updated: "2026-10-12" --- Beta Pi context AGENTS.md governance # pi-context-tree An extension for the Pi coding agent that injects the right context at the right time, by path and operation, from CONTEXT.json files versioned in the repository. Install `pi install git:github.com/ZEDIUM-Off/pi-context-tree` Young tools: read the repository README before installing. **12** commits / 12 months **Latest version** v0.4.2 **stars** 0 **forks** 0 **contributor** 1 **open issues** 0 **Last commit** 4 May 2026 Commits per month. Last 12 months, each repository on its own scale. GitHub figures taken on 12 October 2026. **Source code** [github.com/ZEDIUM-Off/pi-context-tree](https://github.com/ZEDIUM-Off/pi-context-tree) **Licence** MIT licence **Status** Beta ## What it does pi-context-tree moves context routing out of model behaviour and into repository configuration. Instead of asking the agent to remember to read the docs, each folder declares, in a `CONTEXT.json` file, which files or URLs to inject for which path and operation. Rules fire on precise events (session start, agent start, tool calls, subagent spawn), with budgets that bound what gets injected. The extension ships configuration and audit skills, plus commands to check status and validate the configuration. It is a primitive I recommend to teams: context becomes deterministic, auditable, and lives next to the code it describes. [Source code](https://github.com/ZEDIUM-Off/pi-context-tree) ## When to reach for it - Your agents forget project rules as soon as the conversation grows. - You burn tokens loading a global prompt that only concerns part of the repository. - You want injected context to be reviewed like code. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "pi-runtime-monitor, a Pi subagent monitor" description: "A lightweight Pi extension that shows, in the footer, the CPU, memory and aggregated usage of your session’s subagents." url: "https://mc-stud.io/en/open-source/pi-runtime-monitor" lang: "en" updated: "2026-10-12" --- Beta Pi subagents monitoring # pi-runtime-monitor A lightweight Pi extension that shows, in the footer, the CPU, memory and aggregated usage of your session’s subagents. Install `pi install git:github.com/ZEDIUM-Off/pi-runtime-monitor` Young tools: read the repository README before installing. **3** commits / 12 months **Latest version** v0.1.1 **stars** 0 **forks** 0 **contributor** 1 **open issues** 0 **Last commit** 20 July 2026 Commits per month. Last 12 months, each repository on its own scale. GitHub figures taken on 12 October 2026. **Source code** [github.com/ZEDIUM-Off/pi-runtime-monitor](https://github.com/ZEDIUM-Off/pi-runtime-monitor) **Licence** MIT licence **Status** Beta ## What it does pi-runtime-monitor adds a status line to Pi’s footer: process ID, CPU, resident memory and the aggregated usage of the subagents linked to the session. Measurements are sampled every two seconds. The extension has no runtime dependencies, no network access, no telemetry and stores nothing. It reloads in an open session with `/reload` and uninstalls with `pi remove`. [Source code](https://github.com/ZEDIUM-Off/pi-runtime-monitor) ## When to reach for it - You run several subagents in parallel and want to see what they cost the machine. - A session slows down and you want to know who uses what. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "plan-writer, an implementation-plan skill" description: "My shared agent skills, installable with the skills CLI; for now plan-⁠writer, which helps write structured implementation plans." url: "https://mc-stud.io/en/open-source/skills" lang: "en" updated: "2026-10-12" --- Experimental skills planning agents # plan-writer My shared agent skills, installable with the skills CLI; for now plan-⁠writer, which helps write structured implementation plans. Install `npx skills add ZEDIUM-Off/skills` Young tools: read the repository README before installing. **4** commits / 12 months **stars** 0 **forks** 0 **contributor** 1 **open issues** 0 **Last commit** 11 October 2026 Commits per month. Last 12 months, each repository on its own scale. GitHub figures taken on 12 October 2026. **Source code** [github.com/ZEDIUM-Off/skills](https://github.com/ZEDIUM-Off/skills) **Licence** MIT licence **Status** Experimental ## What it does This repository gathers the skills I choose to publish. For now it holds one: plan-writer, which guides the agent in writing a structured implementation plan that can be reviewed and discussed before the first line of code. Installation goes through the `skills` CLI, which copies the repository’s skills and makes them available to your compatible agent. The other skills in my workshop stay private until they are generic enough to be useful elsewhere. [Source code](https://github.com/ZEDIUM-Off/skills) ## When to reach for it - You want the agent to produce a reviewable plan before writing code. - You are looking for an example of a short skill focused on a single procedure. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "Zedflow, a typed agent flow engine" description: "A local engine and studio for typed agent flows: each flow is a graph validated before it runs, with human approvals and a trace of every turn." url: "https://mc-stud.io/en/open-source/zedflow" lang: "en" updated: "2026-10-12" --- Experimental agent flows Rust graphs human approval # Zedflow A local engine and studio for typed agent flows: every flow is a graph validated before it runs, with controlled context, human approvals and a trace of every turn. Install `git clone https://github.com/ZEDIUM-Off/zedflow && cd zedflow && pnpm --dir web install --frozen-lockfile && pnpm --dir web build` Young tools: read the repository README before installing. **678** commits / 12 months **Latest version** v0.2.0 **stars** 0 **forks** 0 **contributor** 1 **open issues** 33 **Last commit** 3 October 2026 Commits per month. Last 12 months, each repository on its own scale. GitHub figures taken on 12 October 2026. **Source code** [github.com/ZEDIUM-Off/zedflow](https://github.com/ZEDIUM-Off/zedflow) **Licence** Source available, non-commercial use (PolyForm Noncommercial 1.0.0) **Status** Experimental ## What it does Zedflow is an engine and studio for agent harnesses. A flow is a strict, typed graph, validated before it runs. Before every model call, a context strategy composes exactly what the agent receives; state lives in typed stores, not in the prompt. Bridges connect flows to each other, and every turn is traced. The web studio lets you draw flows, tune context strategies, launch runs and inspect each turn. The `zf` CLI validates, compiles and runs the same definitions. The command above builds the studio; the daemon is then started with Cargo, as described in the README, with a demo provider that needs no account and no real model. Zedflow is in preview and licensed under PolyForm Noncommercial: commercial use needs a separate agreement. [Source code](https://github.com/ZEDIUM-Off/zedflow) ## When to reach for it - A single agent loop is no longer enough and you want to compose specialised flows. - You need to reread what each agent received and did, turn by turn. - Some steps must wait for a human approval on precise data. ## Let’s talk about what AI could change for you A 30-minute discovery call, by video and with no commitment, to talk about your project, your constraints and the best next step. [Book a call](https://calendar.app.google/VQTPrCgNvQSNwdA7A) [contact@mc-stud.io](mailto:contact@mc-stud.io?subject=First%20call) *** --- title: "Legal notice" description: "Publisher, host and legal information for mc-stud.io (MC Studio, a French EURL)." url: "https://mc-stud.io/en/legal-notice" lang: "en" updated: "2026-10-12" --- Legal information # Legal notice Who publishes this site, who hosts it and how to reach me. This information is published as required by Article 6 of the French law of 21 June 2004 on trust in the digital economy (LCEN). ## Site publisher **Company name** MC Studio (MCS) **Legal form** single-member limited liability company (EURL) **Share capital** €1,000 **Registered office** 47 impasse du Bergeron, 38290 Frontonas, France **SIREN** [100 627 207](https://annuaire-entreprises.data.gouv.fr/entreprise/100627207) **SIRET** [100 627 207 00010](https://annuaire-entreprises.data.gouv.fr/entreprise/100627207) **Registration** RCS Vienne 100 627 207 **VAT number** FR 76 100627207 **Publication director** Matisse Chenavas, manager **Email** [contact@mc-stud.io](mailto:contact@mc-stud.io) **Phone** [+33 6 51 09 63 02](tel:+33651096302) ## Hosting **Host** [Cloudflare, Inc.](https://www.cloudflare.com/) **Address** 101 Townsend St, San Francisco, CA 94107, USA **Phone** +1 (650) 319-8930 ## Intellectual property The texts, visuals and graphic elements of this site belong to MC Studio unless stated otherwise (client and technology logos remain the property of their owners and appear only to illustrate my work). Any reproduction or reuse by a person beyond a short quotation requires my prior written consent. Crawling this site by the indexing and training bots named in the robots.txt file is, however, allowed, including for training models: that file records my decision. The portraits of Matisse Chenavas on this site are AI-generated images based on his own photographs. The tools presented on this site remain under the licence stated in their repository. The software components, typefaces, search model and technology logos used here, with their licences and authors, are listed on the [credits and licences](https://mc-stud.io/en/credits) page. ## Liability and external links I take care to keep the published information accurate, without being able to guarantee that it is complete or current. This site links to third-party sites (LinkedIn, GitHub, Google Calendar for booking, Hugging Face for the search model) whose content and practices I do not control. ## Personal data Personal data processing is described in the [privacy policy](https://mc-stud.io/en/privacy). This site sets audience-measurement cookies only with your consent, which you can withdraw at any time from the footer. ## Accessibility I work to keep this site readable and usable by everyone (keyboard navigation, contrast, alternative text, respect for motion preferences). If you meet a barrier, write to [contact@mc-stud.io](mailto:contact@mc-stud.io) and I will fix it or offer an alternative. ## Governing law This site is governed by French law. French courts have jurisdiction, subject to mandatory rules that apply. Last updated: 12 October 2026 *** --- title: "Privacy policy" description: "Which personal data this site processes, why, for how long, and how to exercise your rights." url: "https://mc-stud.io/en/privacy" lang: "en" updated: "2026-10-12" --- Personal data # Privacy policy This site collects almost nothing: no form, and audience measurement that only starts with your consent. Here is what is processed, and your rights. ## Data controller MC Studio, a French EURL, represented by its manager Matisse Chenavas, whose details are in the [legal notice](https://mc-stud.io/en/legal-notice). Contact for any question about your data: [contact@mc-stud.io](mailto:contact@mc-stud.io). No data protection officer is appointed. ## What this site does not do - no measurement cookie set, and no request to Google, until you accept (only your choice is remembered, see below); - no advertising and no ad tracking: Google’s advertising signals stay denied even if you accept audience measurement; - no font, video or map loaded from a third-party service: fonts are hosted with the site; - no form: you reach me by email or through a booking link. ## Cookies and audience measurement Your choice. On your first visit a banner lets you accept or refuse audience measurement, with equal ease. Your choice is remembered in your browser’s local storage (key mcs-consent: accepted or refused, and the date) for 6 months at most, after which you are asked again. This storage is strictly necessary to respect your choice: it is never transmitted and needs no consent. The "Cookie settings" link in the footer reopens the choice at any time. Audience measurement, with your consent only. If you accept, the site loads the Google tag for Google Analytics 4 directly (Google Ireland Limited for the European Economic Area, Google LLC in the United States). Purpose: to know which pages are read and where visitors come from, in order to improve the site. Legal basis: your consent (GDPR Article 6(1)(a); Article 82 of the French Data Protection Act). Data: pages viewed, date, device and browser type, referrer, approximate location and a pseudonymous identifier stored in the _ga and _ga_KQZQ94SPP8 cookies. According to Google, Google Analytics does not log or store IP addresses. I am the controller of this processing; Google acts as a processor for Google Analytics. Retention. Google cookies: 13 months at most. Data in Google Analytics: 14 months at most, then automatic deletion. Your consent choice: 6 months. Withdrawing consent. Choose "Refuse" in "Cookie settings": the Google cookies are deleted, the page reloads and nothing more is sent to Google. Withdrawal does not affect processing already carried out. You can also delete cookies from your browser settings. Site search. Keyword search runs entirely in your browser: your queries are sent nowhere. The site never writes what you type into the page address: on the search page it is kept in the part of the link after the "#", which your browser never sends to a server, and that part is not written if you accepted audience measurement. One exception for an old shared link: if it contains "?q=", that address reaches the host like any other request before the page removes it from the address bar and turns it into internal state; the page does this before any Google code is loaded, and the Google code never receives its full address. If you turn on semantic search, after reading the box that explains it and clicking "Download and turn on", your browser downloads an artificial intelligence model once (Google’s EmbeddingGemma 2, Apache 2.0 licence, about 165 MB) from Hugging Face, the repository where Google publishes its models, keeps it in its cache (Cache Storage) and runs it locally. This download is a request from your browser to a third party: Hugging Face, Inc. (a US company) and its delivery network then receive your IP address and the usual technical data of a request (browser, date), but neither your search nor the page you are reading: only the site’s name (mc-stud.io) accompanies the request. No request to Hugging Face is made before that click. Afterwards the model is read from your cache, with no new request, for as long as the files remain there; if your browser has erased any of them, the page asks you again before downloading them once more. One exception, for a download you confirmed: if the page is reloaded or closed before it ends, the download carries on by itself, from the parts already verified, as soon as you open a page of the site within the next 24 hours, unless you cancel it ("Cancel the download" in the search details, or the "Semantic search" switch turned off, in any tab). A download that failed, was cancelled or is older than 24 hours, or whose files the browser has erased, is asked again before any new request to Hugging Face. If your browser refuses to keep the model (full storage, private browsing), the page tells you and the model will have to be downloaded again, with your agreement, on a later visit. Hugging Face’s processing is governed by its own privacy policy: [huggingface.co/privacy](https://huggingface.co/privacy). In the search, turning the switch off keeps the model files, while "Delete the model from this browser" erases them and forgets your choice. The runtime (WebAssembly, 22 to 34 MB) and the manifest are still served by this site. Your preference is stored in local storage (key mcs-search-semantic) and only serves the feature you asked for. While a download runs, a second marker is stored there (key mcs-search-semantic-resume: the model’s checksum, the time of your confirmation and, once the first part is saved, a flag); it enables the resumption described above, expires after 24 hours and disappears as soon as the download finishes, fails or is cancelled. You can delete these markers, and the model, from the search or from your browser settings. ## The actual processing Emails. When you write to [contact@mc-stud.io](mailto:contact@mc-stud.io), I process your address, your name if given and the content of your message to reply and, where relevant, to prepare a collaboration. Legal bases: pre-contractual steps at your request, then my legitimate interest in corresponding with professional contacts (GDPR Article 6(1)(b) and (f)). Retention: for the duration of the exchange, then at most three years after the last contact if no contract is signed; for a contract, the statutory retention period for accounting and contractual records. Mail is operated by an email service provider acting on my behalf. Booking. The booking button is a link to the [Google Calendar](https://calendar.google.com/) appointment page on Google’s site. The booking button loads nothing from Google until you follow it; after that, if you book, your booking details (name, email address, time slot) are handled on Google’s site under its own privacy policy, and I receive them in my calendar to honour the appointment. Same legal basis and retention as above. Host technical logs. Like any web server, the host ([Cloudflare, Inc.](https://www.cloudflare.com/)) records connection data (IP address, date, requested page, browser type) to deliver the site and protect it against abuse. I do not access them by name and derive no visitor statistics from them. Legal basis: legitimate interest in the security and proper operation of the site. Retention: Cloudflare does not publish a single retention period for its network request logs; its privacy policy says it keeps personal data for as long as its purposes or legal obligations require. If Cloudflare Workers application logs are enabled for this site, they are kept for 3 days (free plan) or 7 days (paid plan), according to Cloudflare’s documentation. I do not export or archive them elsewhere. ## Recipients and transfers outside the EU Your data is neither sold nor passed on. It is accessible to me and to the technical providers acting on my behalf (mail, calendar, hosting, audience measurement with your consent). Google (Analytics, with your consent; Calendar, if you book) and Cloudflare are US companies: transfers rely on the EU-US Data Privacy Framework they participate in or, failing that, on the European Commission’s standard contractual clauses. Hugging Face, Inc. (a US company) is a recipient only if you turn on semantic search after clicking "Download and turn on": your browser then sends it a download request directly, which reveals your IP address and the technical data of the request to it, under its own privacy policy. I do not rely on any particular transfer mechanism for this download; that is why it depends on your explicit choice. ## Your rights You may ask for access to your data, its rectification or erasure, restriction of processing, object to it, or ask for portability (GDPR Articles 15 to 21). Write to [contact@mc-stud.io](mailto:contact@mc-stud.io); I reply within one month. If you believe your rights are not respected, you may lodge a complaint with the [CNIL (French data protection authority)](https://www.cnil.fr/fr/plaintes) (3 place de Fontenoy, TSA 80715, 75334 Paris Cedex 07, France), or with the authority of your own country. Providing your data is optional: without it I simply cannot answer your request. No automated decision-making or profiling takes place. ## Changes If the site ever adds a new measurement tool or third-party content, this page will be updated before it goes live, and consent will be requested where the law requires it. Last updated: 12 October 2026 *** --- title: "Credits and licences" description: "Software components, typefaces, search model and technology logos used by this site, with their authors, licences and the changes made." url: "https://mc-stud.io/en/credits" lang: "en" updated: "2026-10-12" --- Legal information # Credits and licences This site relies on open components and on third-party logos. Here is what is actually distributed with the pages, who wrote it, under which licence, and what I changed. ## Software components and search model The scripts sent to your browser and the semantic search files include the following components. Each is used under the terms of its licence; their copyright notices are reproduced here. - **React** (version 19.2.8) — interface of the interactive islands. Licence: MIT. Copyright (c) Meta Platforms, Inc. and affiliates. [react.dev](https://react.dev/) - **React DOM** (version 19.2.8) — interface of the interactive islands. Licence: MIT. Copyright (c) Meta Platforms, Inc. and affiliates. [react.dev](https://react.dev/) - **Motion** (version 14.0.0) — animations of the interactive islands. Licence: MIT. Copyright (c) 2024 Motion B.V. [motion.dev](https://motion.dev/) - **Astro** (version 7.3.8) — site engine: page navigation and script loading. Licence: MIT. Copyright (c) 2021 Fred K. Schott Copyright (c) 2020 these people Copyright (c) 2019-present, Yuxi (Evan) You and Vite contributors [astro.build](https://astro.build/) - **Lumos for Astro** (version 0.0.5) — Astro components, styles and utilities of the interface (Lumos port for Astro). Licence: MIT. Copyright (c) 2026 Timothy Ricks [github.com](https://github.com/lumosframework/lumos-for-astro) - **Fancy Components** — text and number animations, adapted from Fancy Components. Licence: MIT. Copyright (c) 2024 Daniel Petho [fancycomponents.dev](https://www.fancycomponents.dev/) - **LiteRT-LM web runtime** (version 0.18.0) — runtime of the semantic search model, served by this site. Licence: Apache 2.0. Google LLC [github.com](https://github.com/google-ai-edge/LiteRT-LM) · [Apache 2.0 licence text](https://mc-stud.io/search-model/LICENSE) · [Notice (NOTICE)](https://mc-stud.io/search-model/NOTICE) - **EmbeddingGemma 2 (270M)** — semantic search model, downloaded from Hugging Face after your agreement. Licence: Apache 2.0. Google LLC [huggingface.co](https://huggingface.co/google/embeddinggemma-2) · [Apache 2.0 licence text](https://mc-stud.io/search-model/LICENSE) · [Notice (NOTICE)](https://mc-stud.io/search-model/NOTICE) ## Typefaces Text is set in Sora and Inter, hosted with the site, under the SIL Open Font License 1.1 (full text below). - **Inter** (version 5.3.0) — body typeface. Licence: SIL OFL 1.1. Copyright 2016 The Inter Project Authors (https://github.com/rsms/inter) [rsms.me](https://rsms.me/inter/) - **Sora** (version 5.3.0) — heading typeface. Licence: SIL OFL 1.1. Copyright 2019 The Sora Project Authors (https://github.com/sora-xor/sora-font) [github.com](https://github.com/sora-xor/sora-font) ## Technology logos Technology logos come from the simple-icons package (CC0 1.0, public domain); the trademarks themselves remain the property of their owners and are shown only to name the technology. Two logos carry attribution terms, given below. - **Rust** — Author: Rust Foundation. Licence: [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). The file provided by simple-icons 16.35.0 carries the CC BY-SA 4.0 licence. The Rust Foundation’s trademark policy, read on 12 October 2026, puts the Rust and Cargo logos under Creative Commons Attribution (CC BY). I apply the stricter terms (CC BY-SA 4.0). Changes: Single-path monochrome version distributed by simple-icons, fill colour set to #000000, scaled when displayed. Source: [rust-lang.org](https://www.rust-lang.org/) · [rustfoundation.org](https://rustfoundation.org/policy/rust-trademark-policy/) - **Git** — Author: Jason Long. Licence: [CC BY 3.0](https://creativecommons.org/licenses/by/3.0/). Creative Commons Attribution 3.0 (CC BY 3.0). Changes: Single-path monochrome version distributed by simple-icons, fill colour set to #F03C2E, scaled when displayed. Source: [git-scm.com](https://git-scm.com/) · [git-scm.com](https://git-scm.com/community/logos) - **Other technology logos**: TypeScript, React, Astro, Node.js, NestJS, Python, PostgreSQL, Docker, NVIDIA, Expo, Coder, Anthropic / Claude, Ollama, vLLM, Hugging Face, Cloudflare, Railway, GitHub, LangChain, Medusa, Pinia, Prisma. ## Client and partner logos Client and partner logos remain the property of their owners. They are taken from their official sites, without an open licence, to illustrate my work. Essan NFC, Santécie, Silico, CICP2R, Cesatec. ## Licence texts Below is the text of the MIT licence, which applies to the components marked MIT, then that of the SIL Open Font License 1.1. The Apache 2.0 licence, which applies to the search model and runtime, is served by this site together with its notice. ### MIT ``` Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. ``` ### SIL Open Font License 1.1 ``` This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL ----------------------------------------------------------- SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 ----------------------------------------------------------- PREAMBLE The goals of the Open Font License (OFL) are to stimulate worldwide development of collaborative font projects, to support the font creation efforts of academic and linguistic communities, and to provide a free and open framework in which fonts may be shared and improved in partnership with others. The OFL allows the licensed fonts to be used, studied, modified and redistributed freely as long as they are not sold by themselves. The fonts, including any derivative works, can be bundled, embedded, redistributed and/or sold with any software provided that any reserved names are not used by derivative works. The fonts and derivatives, however, cannot be released under any other type of license. The requirement for fonts to remain under this license does not apply to any document created using the fonts or their derivatives. DEFINITIONS "Font Software" refers to the set of files released by the Copyright Holder(s) under this license and clearly marked as such. This may include source files, build scripts and documentation. "Reserved Font Name" refers to any names specified as such after the copyright statement(s). "Original Version" refers to the collection of Font Software components as distributed by the Copyright Holder(s). "Modified Version" refers to any derivative made by adding to, deleting, or substituting -- in part or in whole -- any of the components of the Original Version, by changing formats or by porting the Font Software to a new environment. "Author" refers to any designer, engineer, programmer, technical writer or other person who contributed to the Font Software. PERMISSION & CONDITIONS Permission is hereby granted, free of charge, to any person obtaining a copy of the Font Software, to use, study, copy, merge, embed, modify, redistribute, and sell modified and unmodified copies of the Font Software, subject to the following conditions: 1) Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself. 2) Original or Modified Versions of the Font Software may be bundled, redistributed and/or sold with any software, provided that each copy contains the above copyright notice and this license. These can be included either as stand-alone text files, human-readable headers or in the appropriate machine-readable metadata fields within text or binary files as long as those fields can be easily viewed by the user. 3) No Modified Version of the Font Software may use the Reserved Font Name(s) unless explicit written permission is granted by the corresponding Copyright Holder. This restriction only applies to the primary font name as presented to the users. 4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font Software shall not be used to promote, endorse or advertise any Modified Version, except to acknowledge the contribution(s) of the Copyright Holder(s) and the Author(s) or with their explicit written permission. 5) The Font Software, modified or unmodified, in part or in whole, must be distributed entirely under this license, and must not be distributed under any other license. The requirement for fonts to remain under this license does not apply to any document created using the Font Software. TERMINATION This license becomes null and void if any of the above conditions are not met. DISCLAIMER THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. ``` Last updated: 12 October 2026 ***