L'organisation AI-native en pratique

Louis-Marie Simonneaux, étudiant ingénieur à l'ENSEEIHT, a lancé l'an dernier une entreprise individuelle avec deux activités : l'automatisation d'emplois du temps pour des pharmacies et des cinémas, et la création de sites web sur mesure. Il a commencé à coder il y a un an. Il a déroulé, sur un client fictif (un boulanger qui veut refaire son site), toute la chaîne qui va du premier rendez-vous au code livré, pilotée depuis un seul terminal.

Du rendez-vous client aux tickets

• Prise de rendez-vous avec Cal.com. Un lien sur son site ouvre ses créneaux, synchronisés avec Google Agenda : tout ce qui est dans l'agenda disparaît des créneaux proposés. Condition : tenir son agenda à jour avec précision.
• Prise de notes avec Fireflies. L'agent rejoint la visio et note à sa place. Le bénéfice selon lui : au lieu d'écrire, il pose davantage de questions au client pour comprendre son vrai problème. À la fin, Fireflies livre la transcription intégrale et un résumé avec les actions proposées.
• Tickets Linear générés par un skill. Un skill Claude Code lit le compte rendu et crée les tickets (quatre dans la démo), chacun avec des extraits de la réunion et une « définition de fini » qui dit quand le ticket est validé.
• Raycast pour aller plus vite. Ce lanceur pour Mac, plus complet que Spotlight, a des plugins : celui de Linear permet de chercher un ticket et d'en copier l'identifiant sans ouvrir l'application.

Plusieurs agents sur le même projet

• Un template forké. Chaque site client part d'une copie de son template, qui démarre déjà même vide.
• Les worktrees. Chaque agent travaille sur sa propre copie de l'application, sur le même ordinateur. Les agents ne peuvent donc pas écraser le travail des autres. Les modifications sont ensuite fusionnées (merge) dans le dépôt en ligne, puis redescendues en local.
• Un port par ticket. Un script de lancement attribue à chaque ticket son propre port : plusieurs versions de l'application tournent en parallèle, chacune gérée par un agent.
• Herdr pour ne plus jongler entre les fenêtres. Cet outil open source, développé selon lui par une équipe incubée chez Y Combinator, garde Claude Code actif en tâche de fond, même quand on ferme le terminal. Couplé à un VPS, il permet de faire tourner des agents 24 heures sur 24 ordinateur éteint. Il détecte chaque nouvel agent et affiche son état par une pastille : marron quand il travaille, rouge quand il est bloqué par une question, neutre quand il a fini. Des notifications sonores préviennent quand un agent attend. Louis-Marie Simonneaux l'a préféré à son ancienne configuration de quatre terminaux affichés côte à côte.

La démo : quatre tickets en parallèle

• Un skill dit comment, le ticket dit quoi. Il suffit de donner le numéro du ticket : l'agent le lit dans Linear, crée le worktree et l'espace de travail dans Herdr, lance l'application et l'alimente en données de test (un compte utilisateur, un compte admin, du contenu).
• Voir le code en direct. Une seconde fenêtre ouvre Neovim sur les changements en cours, pour vérifier que l'agent part dans la bonne direction. Le site s'administre avec Payload, un CMS open source personnalisable.
• Auto mode, mais pas de commit sans accord. Il travaille en auto mode, qui demande le moins de permissions possible, et dit n'avoir jamais eu de problème. Une règle du skill n'a jamais été enfreinte selon lui : ne pas faire de commit ni de push sans son autorisation. Il relit les changements, autorise l'envoi sur GitHub, fait lui-même le merge et supprime la branche distante. Le skill nettoie ensuite le worktree et passe le ticket en « done ».
• Le résultat. Il travaille aujourd'hui sur six tickets en parallèle sur un même projet. L'étape suivante serait un agent unique par projet qui lance lui-même ces agents en sous-agents, mais il préfère pour l'instant voir tout le code produit, « même si Claude le fait cent fois mieux que moi ».

Cédric Giorgi, développeur de formation qui n'avait pas codé depuis vingt ans, est cofondateur de Sena, qui conçoit des agents IA conversationnels pour les congrès et salons professionnels, déployés notamment sur WhatsApp pour orienter les participants vers les bons stands, les bonnes personnes et les bonnes sessions. Début 2026, le marché s'étant révélé moins grand qu'espéré, l'équipe s'est réduite aux deux fondateurs. Son associé, ingénieur, l'a mis sur Claude Code pour tout ce qui n'est pas le produit : le commercial et le fonctionnement de l'entreprise. Sa présentation avait été générée par Claude, et il a demandé à la salle comment obtenir d'Opus un français qui ne sonne pas comme de l'IA.

Organiser la connaissance

• Une arborescence de fichiers markdown dans GitHub. Même pour un non-développeur, GitHub apporte le suivi des modifications : qui a changé quoi, et la possibilité de revenir en arrière. D'après sa présentation, le principe est « tout est un fichier » : pas d'application ni de base de données, et une décision se révise comme du code. Comme le système sait qui a modifié un fichier en dernier, il cède la place à un humain sans rien configurer.
• Deux briques : la connaissance et les skills. La connaissance, c'est tout ce qui définit l'entreprise : ce qu'elle fait, à qui et à quel prix elle vend, ses clients, son discours, ses concurrents, son positionnement. Elle doit vivre et s'enrichir au fil des clients, comme un cerveau. Les skills sont les comportements qu'on appelle selon le moment.
• Ce que contient le cerveau. D'après sa présentation : le positionnement (ce qu'est l'entreprise, pour qui, à quel prix), les messages (la valeur par segment de clientèle, les chiffres autorisés), la marque (la voix, les mots interdits), une analyse datée par concurrent, un profil par client, et la recherche (la voix du client, des notes de marché). Chaque dossier a sa règle, qui dit ce qui n'y a pas sa place et se charge au moment où l'on y travaille.
• Un chiffre n'a qu'une maison. Les chiffres sont centralisés, avec leur usage : lesquels peuvent aller dans une présentation commerciale, lesquels restent internes. D'après sa présentation, le fichier des chiffres donne pour chacun la valeur, la source et la formulation à ne pas employer, et rien ne sort (présentation, proposition, page) sans passer par lui : « un chiffre sans sa mise en garde finira mal cité ». L'anecdote : un salon client comptait 2 996 exposants, Cédric Giorgi voulait écrire « 3 000 » dans ses présentations, et Claude refusait, parce qu'on lui avait demandé d'être toujours précis sur les chiffres. Savoir quand un arrondi est acceptable reste difficile pour une IA.
• Des connecteurs vers le reste des outils : Linear pour les tâches, Granola pour transcrire les réunions internes et externes, les e-mails en lecture seule. Les deux associés travaillant à distance, avec une heure à une heure et demie d'appels quatre jours sur cinq, ces transcriptions alimentent tout le reste. Sa présentation ajoute le web, pour les sites des organisateurs d'événements.
• Personne ne lance rien. D'après sa présentation, la capture tourne du lundi au samedi à 10 h et la synthèse le vendredi à 17 h. Un seul skill écrit dans la base, les autres ne font que lire. Les livrables (propositions, rapports, contenus) sortent dans un dossier d'attente : c'est un humain qui les valide, et ils ne rentrent jamais seuls dans la base.

Les workflows

• Propositions commerciales en sortie d'appel. Avant, il reprenait ses notes Granola dans un template Notion. Aujourd'hui, une routine quotidienne range les appels au bon endroit, et un skill génère une proposition commerciale ou une présentation de Sena. « Pour les non-dev, tout est code » : une présentation qui est un fichier peut être générée à la volée. Le skill a évolué à l'usage : plutôt que de tout rigidifier, il demande maintenant confirmation de quelques points sensibles, comme le nom de la personne et celui de l'événement, souvent mal compris quand la réunion mêle français et anglais. Il utilise la sortie PDF. D'après sa présentation, le positionnement, le périmètre, le prix, la voix et la mise en page sont tranchés une fois pour toutes en amont : « le skill ne décide rien, ce qui reste est de l'assemblage », et le seul arrêt porte sur les faits (noms, dates, chiffres), jamais sur la rédaction. Pour les e-mails, il reste insatisfait des textes générés dès qu'il s'agit de relation humaine : il les écrit encore à la main, parfois en s'aidant de Gemini, dont il trouve certaines tournures meilleures.
• Un CRM fait maison. Dans son secteur, il faut pitcher un événement ni trop tôt ni trop tard (pas à quatre semaines de sa date ; entre six semaines et six mois avant, d'après sa présentation), et un événement perdu revient l'année suivante. Mettre le CRM à jour à la main l'ennuyait. L'équipe a d'abord décrit le comportement attendu de l'assistant commercial, et cette description est devenue la spec du CRM : les champs sont venus en dernier. Une routine mensuelle vérifie sur les sites des événements du pipe la date de leur prochaine édition. Les discussions internes mettent le CRM à jour. Le système lit les e-mails automatiquement, là où l'ancienne méthode de mise en copie cachée du CRM s'oubliait une fois sur deux, et demande quand il n'est pas sûr. Il remplace aussi un vieux dossier « en attente de réponse » par des alertes sur les personnes à relancer. Il ne lit pas WhatsApp. Sa présentation résume : un CRM classique attend qu'on le remplisse, celui-ci écoute et prend l'initiative de prévenir.
• Un suivi des tâches issues des réunions. Malgré les notes Granola, les petits sujets des réunions quotidiennes se perdaient. Un traqueur les récupère désormais automatiquement. Règle ajoutée à l'usage : un sujet qui revient deux fois gagne en priorité. D'après sa présentation, un audit chaque vendredi applique une définition précise : une tâche est « oubliée » au bout de 14 jours ou quand elle revient deux fois, en « écart » quand elle est close dans Linear mais encore ouverte dans le suivi, et « en pause » quand c'est une décision et non un oubli. La capture écrit, l'audit ne fait que lire. Comme lire du markdown dans un terminal devenait pénible, Cédric Giorgi s'est fait une interface locale, connectée à Linear pour les sujets techniques, avec un bouton pour mettre un sujet en backlog. Pour lui, c'est là que les non-développeurs gagnent le plus : ces petits outils internes ne sont jamais la priorité des développeurs, qui peuvent se concentrer sur le produit.
• La mise en place d'un client. Présenté dans ses slides mais pas détaillé à l'oral : un savoir que seule une personne maîtrisait est devenu une séquence de quatre étapes dans un ordre fixe (configurer, charger le programme et les partenaires, enrichir avec qui veut rencontrer qui, ouvrir le canal). Chaque étape déclare ce qu'elle fait, ce qu'elle ne fait pas et qui s'en charge à sa place. Le risque, selon la présentation, n'était pas une étape mal faite, mais la bonne étape au mauvais moment, sur des données réelles.
• Rapports post-événement et études de cas publiques. Le même skill produit le rapport pour le client et une page publique de showcase. Tout l'enjeu est d'apprendre à l'IA ce qui peut être public : par exemple, la liste des exposants les plus recommandés par l'agent aux participants intéresse beaucoup le client, mais reste privée. D'après sa présentation, chaque chiffre du rapport est recalculé en rapprochant ce que le système dit avoir envoyé et ce qui a réellement été livré, et le volet public part toujours du rapport déjà livré, avec une liste fixe d'informations qui ne sortent jamais (les identités, le détail commercial propre à l'organisateur).
• Un expert de l'événementiel à consulter. Les rapports sectoriels qu'on enregistre « pour plus tard » servent de base à un analyste du secteur que Cédric Giorgi peut invoquer pour être challengé. Un skill d'ingestion extrait l'essentiel de chaque document, un second l'invoque. Ce n'est pas du RAG : il ne s'agit pas de retrouver une information précise, mais de donner le meilleur contexte. Et dans ce rôle, l'agent a pour consigne d'ignorer tout de Sena, pour ne pas être biaisé. Sa présentation parle d'un « mur » : le corpus passe, le positionnement de l'entreprise non, sans quoi l'analyste lui renverrait son propre argumentaire.

Ce que le système ne fait pas

D'après sa présentation, trois propriétés tiennent l'ensemble : tout est un fichier, la capture et la synthèse sont séparées, et par défaut tout tourne seul, l'intervention humaine étant l'exception. Et trois limites, « dites à voix haute » : le système ne connaît que ce qu'il entend (un appel non enregistré n'existe pas pour lui), il n'a été éprouvé qu'à deux personnes, et il garde le discours cohérent, pas forcément juste. Sa présentation se termine sur Hundredfold, l'activité de Cédric Giorgi qui installe ce type de système chez des dirigeants d'entreprises établies.

Deux environnements séparés

Cédric Giorgi fait tourner deux environnements Claude distincts pour ses différentes activités, sans porosité entre eux, une « muraille de Chine ». La limite apparaît quand un besoin concerne les deux, comme l'analyse de son réseau LinkedIn, et qu'il faut revenir sur des consignes de séparation données pendant des mois.

Jean-Baptiste Fleury (Tiple, Oto.cx) est consultant IA, au sein d'un collectif de trois ingénieurs entrepreneurs qui automatisent les opérations des entreprises. Ils forment « monsieur tout le monde » à Claude Cowork, développent de petits ERP (selon lui, 5 000 euros au maximum pour une TPE) et des connecteurs MCP sur mesure. Exemple récent : un MCP branché sur Sellsy, avec son skill intégré, a divisé par quatre le temps de rédaction de devis de 150 à 200 lignes dans une TPE industrielle.

Construire un skill de SAV à partir de l'historique

• Un process qui appartient à l'entreprise. Un skill est interopérable avec Codex ou d'autres outils : si Claude disparaît, l'entreprise garde ses données et son process.
• Partir de la matière existante. Pour une start-up de l'énergie, qui doit tourner avec le moins de ressources humaines possible, trois documents de process et 300 e-mails de support couvrant trois ans d'historique.
• Demander à Claude où sont les trous. L'analyse a produit deux questionnaires de 30 minutes, passés en visio avec les deux responsables du SAV et enregistrés : leurs réponses ont formé un corpus de plus.
• Des tests d'abord, comme en TDD. À partir des e-mails, Claude a généré 25 scénarios de questions-réponses aussi variés que possible. Ils servent de critère de réussite : tant qu'ils ne passent pas tous, l'agent recommence. Claude a ainsi travaillé seul pendant deux à trois heures, sans le solliciter toutes les cinq minutes.
• Un skill de 36 fichiers. Base de connaissances et mode opératoire (analyser la demande, consulter la base, récupérer les données du client…). Le SKILL.md ne décrit que l'arborescence et la façon d'y naviguer. Pas de RAG.
• Un connecteur vers la base clients. Pendant que le skill se construisait, Jean-Baptiste Fleury a développé un MCP qui donne accès aux devis et factures du client.
• Le résultat. 95 % du SAV automatisé, et aucun envoi sans validation, parce que le SAV touche au juridique et au financier. Les 5 % restants : relire, modifier, valider.
• Une boucle d'amélioration continue. Après une séance de test avec la responsable du SAV, sa transcription a servi à améliorer le skill, repassé ensuite aux 25 tests. Désormais, chaque semaine, les e-mails des sept derniers jours mettent le skill à jour, avec validation par la responsable.
• Les tests servent aussi à choisir le modèle. Le même jeu de tests tourne sur Opus, Sonnet et Haiku (trois sous-agents qui lancent chacun 25 sous-agents), ou sur Codex et Mistral, pour descendre d'un modèle quand c'est possible. Le skill étant utilisé plusieurs fois par jour, le coût compte. « Ça crame du token, mais c'est de l'investissement. »

Le loop prompting

Laisser Claude travailler plusieurs heures d'affilée sur un bon prompt initial, qui prend 20 à 30 minutes à écrire. Son record : huit heures. Il en fait tourner cinq en parallèle, et estime sa productivité multipliée par cinq. Cela pose une question qu'il n'a pas tranchée : comment facturer au TJM un travail qui ne lui a pris que quinze minutes ?

Le harnais (sujet choisi par la salle)

Pour Jean-Baptiste Fleury, « c'est votre harnais qui compte, pas le modèle ». Il le découpe en six parties, communes à tous les assistants, et c'est ce harnais qui rend indépendant d'un fournisseur.

• Mémoire et cartographie. La mémoire contient les valeurs sûres : le ton de l'entreprise, ce qu'on veut que l'agent sache à chaque fois. La cartographie indique où vit le reste de l'information (Notion, SharePoint), sans tout recopier. Il utilise souvent des fichiers en local, parfois Notion via son connecteur. La mémoire intégrée de Claude marche très bien selon lui. Git est trop technique pour ses clients, même formés.
• OneDrive plutôt que Git. En synchronisant une partie de SharePoint sur le disque avec OneDrive, Claude Cowork dispose d'une mémoire locale partagée et collaborative, moins puissante que Git mais plus accessible.
• Connecteurs. Les indispensables (mail, agenda, fichiers), les sources publiques et les connecteurs sur mesure. Le MCP de data.gouv est « une mine d'or » pour la prospection : à partir d'un petit formulaire, un skill sort une liste d'entreprises et leurs SIREN, les enrichit jusqu'aux profils LinkedIn et numéros de téléphone, puis les envoie dans Lemlist ou Emelia.
• Skills. « Un skill, c'est juste une procédure. » Sa méthode pour les non-techniciens : faire son process à la main avec Claude, étape par étape, puis lui demander d'en faire un skill, et enfin de l'optimiser avec du code Python. Un participant d'une de ses formations, sceptique au départ, a ainsi divisé par trois sa consommation de tokens sur une étude photovoltaïque (données d'ensoleillement, génération de Word et d'Excel), qui est passée de deux heures à cinq minutes.
• Instructions (CLAUDE.md dans Claude Code, instructions dans Claude Cowork) : voir ses règles plus bas.
• Tâches planifiées. Un skill qui se lance tout seul. Pour une équipe commerciale, trois skills et trois tâches planifiées de reporting, nettoyage et enrichissement sur HubSpot font gagner environ 3 h 30 par semaine au responsable commercial.

Jean-Baptiste Fleury et ses associés envisagent de créer un outil pour construire son propre harnais, sur lequel brancher n'importe quel modèle. Leur métier, dit-il, n'est pas d'aider les entreprises à choisir un LLM, mais à construire leur harnais.

Ses règles d'instructions

Tirées des douze règles qu'il place dans ses instructions :

• Toute affirmation porte sa source, interne ou web.
• Quand tu ne trouves rien, dis-le, ou prouve ce que tu avances. N'invente rien.
• Pose de vraies questions : le contexte, la décision à prendre et ta recommandation. Après une heure et demie sans échanger avec un agent, on a perdu le fil, et la charge mentale devient énorme quand une douzaine d'agents tournent en même temps.
• Résume ce que tu as fait à la fin d'une longue session, et seulement là.
• Quand tu appelles un sous-agent, applique l'art du prompting : donne-lui l'objectif et la méthode.
• Ne produis pas de Word, d'Excel ou de PDF sans demander : c'est lent et coûteux en tokens.
• Utilise un mot plutôt que cinq (dans l'esprit du skill Caveman).
• Apprends de mes corrections et mets à jour tes instructions et ta mémoire, en demandant validation à chaque modification.