La méthode Luge

La plus grosse heure de travail de la journée est deux heures du matin. Il n'y a personne devant l'écran.

Luge est une plateforme où des collègues IA travaillent sur les mêmes objets que les humains — cartes, notes, tables, réunions. Elle est développée par une seule personne, qui la fait tourner sur elle-même : le tri du backlog, la rédaction des tickets, la veille technologique et la composition des journées passent tous par le produit en cours de construction. Une bonne part se fait pendant qu'elle dort.

Cet article n'est pas une démonstration commerciale. Il décrit un fonctionnement réel, relevé sur l'instance : où passe exactement la frontière entre ce qu'un agent fait seul et ce qui attend une décision humaine, ce que cette délégation exige en retour comme discipline écrite — et ce dont elle ne dispense jamais.

Relevé le 25 août 2026 · chiffres et prompts pris sur l'instance · bancs d'essai exclus

Les compteurs, le jour du relevé :

• 5 boards
• 1 251 cartes créées
• 13 tâches actives
• 5 workflows actifs
• 89 skills
• 8 tables

Le contexte

Un développeur, une plateforme, une flotte

Luge est un collègue qu'on ajoute à l'équipe — avec une mémoire, des compétences, l'accès aux outils de l'organisation, et la charge de faire le travail plutôt que d'en parler. Ce n'est ni un assistant de conversation ni une passerelle vers les messageries existantes : c'est un espace de travail complet, où les canaux, les tâches, les documents et les réunions sont natifs, et où des agents y agissent au même titre que les personnes.

Le produit couvre sept territoires : les conversations et les collègues IA, la voix et les réunions, la mémoire, les documents et les notes, les tableaux et la planification, les tables et les livrables, les automatisations et les workflows — le tout sous des règles d'accès, d'audit et de conformité pensées pour des secteurs qui en exigent.

Ces territoires ne vivent pas dans une seule fenêtre. Luge s'atteint depuis le navigateur, une application de bureau, une application mobile, une ligne de commande, un kit de développement — et un runtime qui s'installe sur la machine de l'utilisateur pour y faire tourner un modèle en local, transcrire sans que l'audio sorte, et exposer les outils de cet ordinateur. Un espace partenaire permet par ailleurs de revendre la plateforme en marque blanche, sous une autre identité que la sienne.

Voilà pour le produit. Le fait décisif est ailleurs, et il change la lecture de tout ce qui suit.

Ce qui suit n'est donc pas un confort d'organisation. C'est la condition de possibilité du projet. Une personne seule ne peut pas relire trois cents cartes par semaine, vider une boîte de captures tous les soirs, analyser chaque lien de veille et rédiger des tickets documentés au fichier et à la ligne près. Ce sont des agents qui le font, dans l'outil, la nuit.

Et ça pose la contrainte inverse de celle d'une équipe. Dans une équipe, un travail bâclé finit par être vu par quelqu'un d'autre. Ici, personne ne relit derrière — d'où des règles écrites, des frontières explicites, et une preuve exigée avant qu'une carte soit close. La rigueur n'est pas une préférence de tempérament, c'est le seul filet.

Le principe

L'agent instruit, l'humain tranche

La règle qui organise tout le reste tient en une phrase : un agent a le droit de préparer une décision, jamais de la prendre à la place de l'humain quand elle est irréversible ou coûteuse.

Ça n'a l'air de rien, mais c'est ce qui permet de laisser tourner une flotte d'agents sans surveillance. Chaque automatisation porte une frontière écrite noir sur blanc : ce qu'elle fait seule, ce qu'elle se contente de proposer. Rien n'est laissé à l'appréciation du modèle au moment de l'exécution.

Une carte n'est pas un post-it. C'est un dossier d'instruction, rédigé par un agent, validé par un humain.

Le corollaire est une exigence de fond : on corrige à la cause. Une carte qui propose de relever une limite plutôt que de réduire le coût qui la fait sauter se fait retoquer — c'est écrit dans les tickets eux-mêmes.

La journée

Feuille de marche

Douze tâches planifiées actives, réparties sur vingt-quatre heures. Le gros du travail de mise en ordre est fait avant le réveil.

• Autonome
• Attend une réponse humaine

1. 02:00
   PO — pipeline nocturne Le Product Owner ouvre le board : il vérifie les 25 cartes en attente de preuve de livraison, toilette trente cartes de la pile des « à faire », et rédige son rapport. Il ne regarde ni les archives ni les cartes en cours. quotidien · budget 30 cartes · rapport en DM
2. 03:00
   Inbox refinement Vide la boîte de captures : chaque note jetée à la volée devient des tâches réelles, la note est restructurée sur place, retitrée, et sort de la file. quotidien · jamais de note écrite à côté, jamais de contenu perdu
3. 07:15
   Revue des notes en attente Ferme les notes dont toutes les tâches sont faites, crée celles qui manquent. Ce qui doit sortir vers l'extérieur passe d'abord par une demande à l'humain. jours ouvrés · jamais de réécriture, une note par tour
4. 07:30
   Plan de journée Compose la journée autour des réunions déjà là — cartes assignées, tâches personnelles, blocs libres — puis la soumet pour validation au lieu de l'appliquer. jours ouvrés · mode proposition · ne vide jamais la journée
5. 08:45
   Daily scrum Le point quotidien, déclenché par une commande d'une ligne qui charge tout son mode d'emploi. jours ouvrés
6. 09:00
   Check-in du matin Humeur, énergie, une note si le cœur y est. La réponse ne part pas dans le vide : elle s'écrit dans une table, et devient une série qu'on peut relire. quotidien · 53 relevés · voir « la mémoire »
7. 09:00
   Rendez-vous et tâches du jour Deux tâches parallèles : les prochains rendez-vous tirés du calendrier, et le rappel des tâches en cours par message direct. quotidien
8. 08–16
   Triage des courriels Toutes les heures pendant la journée de travail : classe les non-lus en « à lire / action » et « candidats à la suppression ». Ne supprime rien. jours ouvrés · neuf passages
9. 20:58
   Nouvelles du Québec Cinq à huit nouvelles, chacune avec sa source et son lien. Pas de lien, pas de nouvelle : la règle est dans le prompt. quotidien · huit médias listés · quinze mots de citation maximum
10. vend.
    Résumé technologique de la semaine Reprend les 128 cartes de veille et publie la synthèse hebdomadaire dans le canal de l'équipe. hebdomadaire

La pièce maîtresse

L'agent qui range le board pendant la nuit

À deux heures du matin, un agent Product Owner ouvre le board principal. Il commence par mettre à jour le dépôt de code — parce qu'il ne va pas juger de la pertinence d'une carte sans lire le code auquel elle se rapporte. S'il n'y arrive pas, il ne force rien, il le note dans son rapport et continue.

Puis il fait deux passes. D'abord les livraisons : les vingt-cinq cartes de la colonne « terminé » sont lues une à une avec leur fil de commentaires. Preuve de livraison — un commit, une pull request, un test de bout en bout ? Il archive. Sinon il commente précisément ce qui manque, et il laisse la carte tranquille. Il ne remet jamais une carte en arrière lui-même. Au passage il signale les cartes « en cours » sans activité depuis trois jours, sans y toucher.

Ensuite le toilettage : trente cartes maximum par nuit, prélevées sur une pile de trois cent cinq, en commençant par les nouvelles puis par les moins récemment revues — il tient lui-même la table qui garde la trace de ses passages. Pour chaque carte, quatre questions : est-elle encore pertinente au vu du code ? la description est-elle actionnable ? la priorité est-elle juste ? est-ce un doublon ?

Quatre garde-fous encadrent tout le passage :

• Jamais de suppression Ni carte, ni board. L'archivage est réversible, la suppression ne l'est pas.
• Jamais les cartes en cours Ce sur quoi un humain travaille en ce moment n'est pas de la matière à ranger.
• Tout changement commenté Sur la carte elle-même. Un changement sans trace est un changement qu'on ne peut pas contester.
• Idempotent Repasser deux fois ne change rien la deuxième fois. C'est ce qui rend une relance sans danger.

Deuxième exemple

De Telegram au canal de l'équipe, sans intervention

La veille technologique suit le même principe, appliqué à quelque chose de banal : lire un lien intéressant et ne pas l'oublier. Le geste humain se réduit à coller une URL dans une conversation Telegram — depuis le téléphone, sans ouvrir d'application de gestion. Tout le reste s'enchaîne.

1. 01 Un lien collé Dans le canal de veille sur Telegram. Un lien, ou dix d'un coup — le traitement par lot est prévu. Humain · 3 secondes
2. 02 Une carte apparaît Un agent crée la carte sur le board de veille : un titre lisible tiré du lien, l'URL en corps de carte. Rien de plus. Agent
3. 03 Assignée à l'IA L'assignation n'est pas administrative : c'est le déclencheur. Une carte confiée à une IA dans cette colonne lance le workflow. Agent
4. 04 Le lien est lu Ce que c'est, comment ça marche, points forts, limites, maturité, cas d'usage. L'analyse est publiée en rapport épinglé sur la carte, qui passe en « terminé ». Workflow · nœud agent
5. 05 Le résumé arrive Titre, quatre à six lignes, verdict — dans le canal de l'équipe. Et en dernière ligne, obligatoirement, le lien analysé. Workflow · nœud notification

Au compteur, le jour du relevé :

• 3 en attente
• 53 analysées
• 73 archivées
• 1 résumé hebdo

Trois cartes seulement attendent leur tour, sur cent vingt-huit. Le tuyau ne bouche pas : la dernière carte a été créée à 16 h 03 et son analyse était publiée avant 16 h 07. Et le vendredi, une tâche hebdomadaire reprend l'ensemble du board pour en tirer la synthèse de la semaine.

Ici, pas d'étape d'approbation, contrairement au board de développement. La raison est cohérente avec la règle mère : rien de ce que fait cette chaîne n'est irréversible. Une analyse ratée se relance, une carte se désarchive, un message de canal se corrige. Là où le coût de l'erreur est faible, l'agent va jusqu'au bout tout seul.

La convention

Ce que contient une carte

Les tickets ne sont pas écrits à la main. Une commande les rédige, à partir du code, selon un gabarit fixe. Le résultat n'est pas une intention vague à décoder plus tard : c'est une enquête déjà faite.

Symptôme

Ce qu'on observe, daté, avec les conditions exactes.

Reproduction

La suite de commandes qui refait apparaître le problème.

Attendu vs observé

Deux lignes. Ce qui devrait arriver, ce qui arrive.

Cause racine (hypothèse)

Avec les fichiers et les numéros de ligne. C'est ce qui distingue un ticket d'une plainte.

Zones impactées

Les fichiers à toucher, tests inclus.

Piste de correction

Où corriger, et pourquoi pas ailleurs.

Critères d'acceptation

Des cases à cocher, mesurables. Pas « ça marche mieux ».

Effort estimé

S, M ou L — et ce qui coûte vraiment, qui n'est pas toujours le code.

_Carte rédigée par /luge-ticket-create : analyse à valider._

Cette dernière ligne est la signature obligatoire. Elle dit deux choses : d'où vient le texte, et qu'il n'a pas encore été validé par un humain. Un ticket rédigé par une machine qui ne le dirait pas serait un ticket qu'on croirait relu.

Le point produit

Une carte est un lieu, pas une fiche

Un dossier d'instruction aussi fourni appelle des questions, et c'est là que la carte cesse de ressembler à un ticket ordinaire : on peut lui parler. Deux portes mènent au même objet, et elles ne servent pas les mêmes moments.

La conséquence tient en une phrase : le board n'est pas un endroit où l'on va, c'est un endroit qui vient. La règle de preuve avait déjà rendu le client en ligne de commande indispensable à la livraison ; elle en fait ici, presque par effet de bord, le moyen d'atteindre le travail depuis n'importe où.

Cette page en est un exemple. Elle a été écrite par un assistant extérieur à Luge, équipé du client en ligne de commande, qui a lu les boards, les cartes, les tâches planifiées, les workflows et les tables sans qu'on lui envoie une seule capture d'écran — et qui a fini par créer une tâche planifiée, une fois l'accord donné.

La règle de livraison

Rien n'est fait tant que la ligne de commande ne le prouve pas

Cette règle a une conséquence qu'on n'anticipe pas : elle fait grossir le client en ligne de commande à la vitesse de la plateforme. Chaque fonctionnalité qui ne pouvait pas être prouvée a forcé l'ajout du verbe qui manquait. Le journal des versions en garde la trace, parfois avec la facture.

La version la plus récente porte cette phrase en tête de son journal : « un client qui peut prouver ce qu'il annonce ». Cinquante-neuf versions publiées, et une bonne part de cette croissance vient de là — pas d'une feuille de route, mais de tickets qu'il fallait pouvoir clore honnêtement.

Cette règle explique aussi ce qui traîne dans l'espace de travail et qu'on prendrait pour du désordre : des tâches et des workflows aux noms d'inventaire, désactivés, portant le numéro de la carte qu'ils ont servi à prouver. Ce ne sont pas des restes d'expérimentation. Ce sont les preuves, laissées en place.

Et la boucle se referme la nuit suivante : l'agent qui range le board n'archive une carte que si son fil contient la preuve de livraison. La règle a son inspecteur.

Le contrepoint

Ce que les agents ne remplacent pas

Tout ce qui précède pourrait laisser croire à une forme de magie : des agents qui rangent, rédigent, analysent et livrent pendant que personne ne regarde. Ce serait mal lire. Rien de tout cela ne dispense des pratiques ordinaires du métier. Les tests tournent, le code est analysé, les dépendances sont auditées, et la chaîne de sortie refuse par défaut.

Quatre barrières successives, chacune à un moment différent, chacune capable de dire non.

1. Avant le commit crochets locaux

   Le premier filet se déclenche sur la machine, avant que quoi que ce soit parte : mise en forme, syntaxe des fichiers de configuration, gros fichiers refusés, conflits de fusion oubliés. Et deux gardes qui ne pardonnent pas — aucune clé privée, aucune instruction de débogage laissée dans le code.

   • ruff — lint
   • ruff — format
   • mypy
   • yaml / toml / json
   • gros fichiers
   • conflits de fusion
   • clés privées
   • traces de débogage
2. À chaque poussée intégration continue

   Sur la branche principale comme sur chaque demande de fusion, sept travaux indépendants, dont un consacré à la sécurité : analyse statique du code à la recherche de motifs dangereux, et audit des dépendances contre les vulnérabilités connues. Un travail préliminaire détecte ce qui a changé pour n'exécuter que ce qui est concerné, et le déclencheur n'obtient qu'un droit de lecture sur le dépôt.

   • détection des changements
   • lint & format
   • code mort
   • types
   • analyse de sécurité
   • audit des dépendances
   • tests
   • concurrence base de données
   • TypeScript côté interface
3. Avant la publication refus par défaut

   La fabrication du paquet passe d'abord par la même série de vérifications que l'intégration continue — impossible de produire un livrable sans elles. Puis deux refus catégoriques : la version publiée doit correspondre exactement à une étiquette posée sur ce commit, et l'arbre de travail doit être propre. Une modification non enregistrée suffit à bloquer.

   • vérifications complètes
   • commit == étiquette
   • arbre propre
   • paquet validé
4. Le déploiement procédure écrite, onze étapes

   La mise en production sur la grappe maison suit un mode d'emploi de trente pages qui annonce d'emblée sa nature : « la procédure ET les pièges réels rencontrés en production — pas une théorie ». Lire le journal des versions et les migrations avant de lancer quoi que ce soit ; déployer la dernière version étiquetée, jamais l'état courant de la branche ; vérifier l'espace disque ; s'assurer qu'aucun déploiement n'est déjà en cours ; suivre la progression sans se fier au seul statut ; écarter les faux positifs déjà connus pour ne pas courir après des fantômes. Le début et la fin sont annoncés dans Luge, par Luge.

   • journal + migrations d'abord
   • dernière étiquette, pas la branche
   • préflight disque
   • sauvegarde
   • migrations idempotentes
   • faux positifs connus
   • annonce début et fin

Le détail qui compte, pour quelqu'un qui travaille seul : la commande locale qui vérifie tout porte le commentaire « ce que l'intégration continue exécute ». Le même contrôle, à l'identique, sur la machine et sur le serveur. Découvrir un échec dix minutes après avoir poussé, quand personne d'autre ne peut reprendre la main, c'est dix minutes perdues pour rien.

Mais le plus instructif est la manière dont le mode d'emploi de déploiement se termine. Il ne prétend pas tout couvrir : il se referme sur trois listes explicites — ce qui est déjà automatisé et qu'il ne faut pas redécouvrir ; ce qui reste un jugement humain et qu'on ne mécanise pas honnêtement ; et les recommandations issues du dernier post-mortem, présentées comme non implémentées.

Cette troisième liste est un aveu, écrit noir sur blanc dans la procédure elle-même. Décider qu'une migration a besoin d'un traitement différé demande de lire un écart de schéma et de raisonner sur une dépendance — « pas un grep mécanique fiable à 100 % ». Décider s'il faut revenir en arrière ou forcer en avant dépend de l'état réel observé. Ces décisions-là ne sont pas déléguées, et la procédure dit pourquoi.

Un agent peut rédiger le ticket, écrire le correctif, prouver qu'il fonctionne et suivre le déploiement. Il ne dispense ni d'une chaîne qui dit non, ni d'une procédure qui sait ce qu'elle ne sait pas.

Les points de contact

Où l'humain reprend la main

Une flotte d'agents autonomes ne vaut que par la qualité de ses interruptions. Il y en a cinq sortes, et chacune a une forme.

Le rapport avec propositions numérotées. L'agent nocturne finit par un message direct : ce qui a été archivé, reformulé, repriorisé, les cartes zombies, et ses propositions numérotées. On répond par les numéros qu'on accepte.

Le mode proposition. Le plan de journée est composé, puis soumis. L'agent a le droit de tout préparer et rien d'appliquer.

La demande explicite. Toute action sortante — envoyer un courriel, publier, écrire à quelqu'un, réserver — passe par une demande formelle à l'humain. Le prompt le dit sans détour : jamais d'action sortante sans accord.

La carte proposée par l'agent de revue. L'agent qui relit le code ne se contente pas de commenter : ce qu'il repère devient une proposition de carte, qui attend la validation avant d'entrer dans le board. C'est la même règle qu'ailleurs — il instruit, il n'inscrit pas. Une revue récente a ainsi donné une série de cartes d'affilée, dont l'une consiste simplement à écrire les notes qui en découlent.

L'étape d'approbation dans un workflow. Quand une carte est assignée à une IA sur le board principal, un agent fait le travail — mais il lui est interdit de marquer la carte terminée. Une étape d'approbation attend l'humain ; ensuite seulement un second agent clôt la carte, ou commente le refus.

La mémoire

Ce que le système garde entre deux passages

Un agent ne se souvient de rien d'une exécution à l'autre. Pour qu'une automatisation quotidienne fasse autre chose que répéter la même chose tous les jours, il lui faut un endroit où déposer ce qu'elle a fait. Ce sont les tables : de petites bases typées, écrites aussi bien par un humain que par un agent ou un formulaire.

Deux d'entre elles portent des morceaux entiers de la méthode.

Le détail qui compte dans la seconde : sur sept colonnes, quatre se remplissent toutes seules. Qui répond, quand, sous quel nom, à quelle adresse — la plateforme les injecte à l'écriture. Le formulaire ne demande que ce qu'une machine ne peut pas deviner. C'est la différence entre un questionnaire qu'on finit par ne plus remplir et un geste de trois secondes qu'on fait tous les matins.

À côté des tables, le journal de l'espace de travail donne l'autre moitié de la mémoire. Les tables gardent des faits comparables dans le temps ; le journal garde le déroulé — heure par heure, ce qui s'est réellement passé dans la journée, à relire le soir.

• 2 h · 45 actions Le plus haut pic de la journée. C'est l'agent nocturne qui range le board — personne n'est devant l'écran.
• 7 h · 32 actions La revue des notes puis la composition du plan, juste avant l'arrivée.
• 22 h · 33 actions La reprise du soir, seule crête où les messages (en bleu) pèsent autant que les objets créés.
• 2 échecs Signalés en rouge sur l'axe, à midi et vers 18 h. Une automatisation qui casse le dit.

Cette courbe est le meilleur résumé de la page. La plus grosse heure de travail de la journée est deux heures du matin, et il n'y a personne pour la voir passer. Le reste se lit tout aussi bien : les creux de la nuit et du milieu d'après-midi, la reprise du soir, et deux échecs qui ne se cachent pas — parce qu'une automatisation qui tombe doit s'annoncer, sans quoi on croit qu'elle tourne.

La boucle

Tout ce qui est vu une fois est consigné

Les agents disposent de 89 modes d'emploi. Une quarantaine d'entre eux ne viennent pas du catalogue de la plateforme : ils ont été ajoutés au fil des jours par une boucle d'amélioration qui lit les conversations réelles, repère les enchaînements laborieux et propose un raccourci.

On peut lire l'origine dans leurs descriptions. L'une d'elles s'ouvre ainsi : « Observation [3] shows a long chain of find_tools, notion-search, and notion-fetch. A dedicated skill can streamline the pattern. » Le motif observé, puis le remède proposé — dans la description du remède lui-même.

Ces propositions ne s'appliquent pas toutes seules quand elles portent à conséquence : celles qui bifurquent restent en attente d'un « non » humain explicite, et tout ce qui a été appliqué peut être remis à son état antérieur, avec la raison consignée.

Ce n'est pas un mécanisme isolé, c'est le même geste répété à trois hauteurs. L'agent de revue consigne ce qu'il voit dans le code et en fait des cartes. La règle de preuve consigne dans le client en ligne de commande chaque manque rencontré en chemin. La boucle d'amélioration consigne les frottements des conversations et en fait des modes d'emploi. À chaque fois : ce qui a été observé une fois devient une trace durable, et cette trace améliore l'outil suivant.

Rien ne se perd en cours de route. Une observation devient une carte, une carte devient un verbe de commande, un frottement devient un mode d'emploi — et le produit avance de tout ce que l'usage lui apprend.

Les cinq boucles du produit — parler et agir, savoir et se souvenir, matérialiser le travail, automatiser, s'améliorer — se lisent alors dans le bon ordre. La cinquième n'est pas la dernière : c'est celle qui rend les quatre autres cumulatives.

La couche d'en dessous

RoomKit, la souplesse vient de là

Un dernier mot sur ce qui rend tout cela possible techniquement, et qui ne se voit nulle part dans l'interface. Quand Luge reçoit un lien collé dans Telegram, envoie un résumé dans Teams, prend un appel téléphonique, transcrit une réunion ou tient une conversation vocale avec interruption, il ne fait pas neuf intégrations séparées : il s'appuie sur RoomKit, un cadre logiciel libre, développé par la même personne.

RoomKit est une bibliothèque Python asynchrone qui ramène toutes ces conversations à un même objet — une « salle » — quel que soit le canal qui y mène. Seize canaux intégrés (SMS, RCS, courriel, WhatsApp, Messenger, Telegram, Teams, Discord, WebSocket, voix, vidéo, conférence…), les fournisseurs de modèles et de téléphonie derrière, un pipeline audio complet avec détection de parole et suppression d'écho, les événements éphémères de présence et de frappe, un stockage remplaçable, et l'outillage d'agents : mémoire, recherche documentaire, appel d'outils, délégation.

Cette séparation n'est pas cosmétique. Elle veut dire que la couche conversationnelle se teste, se mesure et se corrige pour elle-même — le travail en cours sur sa capacité d'ingestion en est l'exemple, mené à coups de mesures et de profils plutôt que d'intuitions. Elle veut dire aussi qu'ajouter un canal à Luge n'est pas un chantier dans Luge.

Et parce que RoomKit est ouvert, le socle sur lequel repose la plateforme est lisible par n'importe qui — ce qui est une façon assez directe de répondre à la question « qu'est-ce qu'il y a vraiment là-dessous ».

Trois lectures

Selon d'où vous arrivez

Relevé directement depuis le board de développement, le 25 août 2026. Les chiffres bougent tous les jours. Luge s'appuie sur RoomKit, cadre logiciel libre — roomkit.live.