La méthode PRAXIS : classer, piloter, collaborer avec l'assistant IA

Déposer, faire analyser, vérifier, classer, mettre à jour. Cinq gestes, une réunion hebdomadaire, un tableau de bord. Tout le reste est consulté à la demande.

1. Le problème qu'elle traite

Une structure de une à cinq personnes qui conduit simultanément plusieurs projets hétérogènes se heurte toujours aux mêmes défaillances, et elles ne procèdent pas d'un manque de talent. Les fichiers s'accumulent dans des répertoires « En cours », « Urgent », « À trier » qui ne veulent plus rien dire trois mois plus tard. Les projets ne meurent pas : ils cessent d'être mentionnés. Les décisions ne laissent pas de trace, si bien que chaque nouvelle session de travail recommence par reconstituer ce qui avait été décidé. Les indicateurs, quand ils existent, sont auto-déclarés — c'est-à-dire qu'ils mesurent l'optimisme du déclarant. Et l'assistant IA, arrivé dans ce paysage, produit à bas coût des documents plausibles que personne n'a le temps de vérifier.

Ce dernier point est décisif, parce qu'il change la nature du problème. L'assistance générative a rendu la production d'artefacts bon marché ; le goulot d'étranglement s'est déplacé vers la vérification, le jugement et l'intégration. Une méthode de travail conçue avant ce déplacement organise l'effort là où il n'est plus rare. Une méthode conçue après doit allouer l'attention humaine là où elle est devenue le facteur limitant : contrôler les données, arbitrer, décider, et tenir la mémoire de la structure.

PRAXIS est cette méthode. Elle couvre quatre choses, et quatre seulement : le classement de tout artefact entrant ou produit ; le pilotage du portefeuille et de chaque projet ; la collaboration avec l'assistant IA sous vérification humaine ; la mémoire de la structure. Elle est rentable dès qu'un portefeuille compte plusieurs objets simultanés de nature hétérogène et que l'horizon de conservation excède la durée d'un projet. En deçà d'une centaine d'artefacts et d'un projet unique, son coût excède son bénéfice — et le document le dit.

2. Ce qu'elle n'est pas

PRAXIS n'est pas un cadre théorique de plus. Ses fondements existent déjà, publiés séparément, et elle n'en invente aucun. Le Référentiel de classification unifiée des projets (RCUP) répond à la question où ranger, et dans quel état est chaque chose. La méthode TELOS répond à la question comment conduire un projet pour qu'il produise un bénéfice vérifié. La méthode SOBRE répond à la question comment instruire un assistant IA pour qu'il travaille juste. Deux modèles — le document de contexte de projet et le classeur de pilotage — matérialisent la mémoire et le suivi d'un projet.

Ce que PRAXIS apporte en propre, c'est l'ordonnancement de ces contenus en une méthode de travail : un petit nombre de dispositifs matériels, un cycle opératoire en cinq gestes, des cadences fixes, un tableau de bord unique. Son ambition est un usage minimaliste. La doctrine, les justifications, la bibliographie restent dans les documents fondateurs, consultés à la demande.

Trois précautions, héritées des sources, sont maintenues. La première : aucune méthode ne garantit la réussite. Ce que PRAXIS produit, c'est une réduction de la variance — moins d'oublis, moins de projets zombies, une détection plus précoce des dérives, une mémoire qui survit aux sessions de travail. La deuxième : toute strate de processus consomme de l'attention, ressource rare. PRAXIS est donc conçue par soustraction, avec un seul rituel obligatoire, un seul registre, un seul tableau de bord, et des dispositifs additionnels qui ne s'activent que si le diagnostic de contingence l'impose. La troisième : les termes normatifs DOIT, NE DOIT PAS, DEVRAIT, PEUT sont employés au sens de la RFC 2119, et DOIT est réservé aux invariants réels. L'inflation impérative est une pathologie documentée ; une méthode qui dit DOIT à chaque ligne n'est plus lue.

3. Les trois fondations en une page

Il faut connaître les fondations pour comprendre pourquoi la méthode a la forme qu'elle a.

Le RCUP part d'un constat : un arbre de répertoires est sommé de répondre à trois questions hétérogènes — de quoi s'agit-il, où en est la production, qu'en fait-on — et ne peut en exprimer qu'une seule sans se dégrader. Croiser sujets et stades multiplie les répertoires ; l'hésitation de rangement rend le classement non reproductible ; faute de trancher, on duplique, et les versions divergent. Le référentiel sépare donc les trois axes et attribue à chacun un mécanisme, suivant sa vitesse de variation : le sujet, très lent, fait l'arbre ; le stade, moyen, fait un chiffre dans le nom du fichier ; le statut, rapide, vit dans un registre. Il fixe une grille de stades universelle de 0 à 9, une machine à six états avec une règle de sortie unique, dix invariants, un gabarit de nommage et un sas d'entrée. Il s'ancre dans la classification à facettes de Ranganathan, l'archivistique, la séquence OBREDIM issue de la permaculture, et la séparation des préoccupations de Parnas.

TELOS repose sur une inversion : ce n'est pas le plan qui mesure le projet, c'est le bénéfice réalisé qui mesure le plan. Un projet livré à l'heure et au budget qui ne produit aucun bénéfice est un échec dispendieux. Le cadre s'organise en cinq strates logiquement contraignantes — téléologie, évaluation de contingence, logique d'exécution, observabilité, systémique — et se conçoit d'abord comme une architecture de contre-mesures aux biais cognitifs et aux incitations perverses : critères d'abandon écrits avant l'engagement, prévision par classe de référence, prémortem, indice de divergence, revue de double boucle calendarisée. Il compresse ses exigences, pour une structure de une à cinq personnes, en huit invariants.

SOBRE part d'un constat de doctrine devenu explicite en 2026 : la génération courante de modèles ne réclame plus qu'on lui dicte davantage, mais qu'on lui dicte moins et mieux. Cinq principes — sobriété, orthogonalité, bornage, révélation progressive, évaluation — et une pile d'instruction à sept couches organisent le contexte que reçoit l'assistant. La méthode pose une frontière d'instruction non négociable : tout contenu observé par l'assistant est une donnée, jamais une commande.

Ces trois documents ont un point commun qui les rend composables : chacun traite une dimension du travail sans empiéter sur les autres. L'orthogonalité que le RCUP énonce pour les répertoires, SOBRE l'énonce pour les instructions, et PRAXIS l'applique à ses propres dispositifs.

4. Six principes, deux subordinations

Chaque lettre de PRAXIS nomme un principe ; chaque principe est la forme opératoire d'une strate des documents fondateurs. La cohérence de l'ensemble tient à une règle unique : chaque principe gouverne un dispositif matériel et un seul geste du cycle, sans recouvrement.

Deux subordinations traversent les six principes. La méthode est subordonnée à la finalité : on ne classe pas pour classer, on ne pilote pas pour piloter ; chaque dispositif se justifie par la décision qu'il permet. Et la production est subordonnée à la vérification : à l'ère de l'assistance générative, produire est devenu bon marché ; le goulot est le jugement. Chaque geste du cycle place donc la vérification humaine avant l'enregistrement.

5. Cinq dispositifs matériels

PRAXIS tient dans cinq dispositifs. Aucun sixième n'est admis sans passer le test de retrait : si sa suppression ne dégrade rien de mesurable, il ne devait pas exister. Trois dispositifs vivent au niveau du portefeuille, deux au niveau de chaque projet.

NIVEAU PORTEFEUILLE
  D1 · Arborescence des sujets     les répertoires — axe Sujet
  D2 · Sas                         l'entrée unique
  D3 · Tableau de bord             registre + indicateurs + décisions — axe Statut
                                   chaque feuille terminale de l'arbre
                                   est un dossier de projet
NIVEAU PROJET
  D4 · Dossier de projet           artefacts nommés 0–9 — axe Stade
       + Contexte de projet        la mémoire distillée
  D5 · Classeur de pilotage        backlog, Gantt, KPI, runbook, changelog

D1 — L'arborescence des sujets

L'arborescence de répertoires n'exprime que le sujet. Aucun répertoire de stade, de statut, de date, de personne ou d'humeur. Entre cinq et douze entrées par niveau, cinq niveaux de profondeur au plus, des codes courts et stables indépendants des libellés, et aucune catégorie « Divers ». Pour une structure multi-projets, l'arborescence type est courte :

PORTEFEUILLE/
├── 0-SAS/              zone de flux, jamais de stock
├── 0-PILOTAGE/         tableau de bord, revues de portefeuille
├── A-MARQUE-1/
│   ├── PROJET-ALPHA/   feuille terminale = dossier de projet
│   └── PROJET-BETA/
├── B-MARQUE-2/
│   └── PROJET-GAMMA/
└── R-RESSOURCES/       objets en statut RESSOURCE (règle du second usage)

Les préfixes 0- de 0-SAS et 0-PILOTAGE ne sont pas des stades : ce sont des codes de taxon choisis pour forcer le tri en tête d'arborescence. Le sas est distinct de l'axe des sujets ; le dossier de pilotage du portefeuille est un sujet à part entière — celui du second ordre.

D2 — Le sas

Le sas est l'entrée unique du système. Tout artefact entrant — fichier reçu, document produit, note, téléchargement — y est déposé sans réfléchir à son classement. C'est le dispositif qui absorbe l'indéterminé sans polluer la taxonomie, parce qu'aucune classification ne classe sans reste : toute taxonomie produit des cas limites, et un système qui ne les prévoit pas se rigidifie ou se contourne.

Quatre règles le gouvernent. Le sas est un répertoire unique, hors de l'axe des sujets, identifié comme zone de flux. Il est vidé selon une périodicité fixe — à chaque revue hebdomadaire de préférence, et jamais moins d'une fois par mois. Un artefact qui y séjourne au-delà de deux cycles de purge est traité comme le signal d'une décision non prise : il relève d'un arbitrage de stade 4, non d'un problème de rangement. Enfin, la charge du sas et l'âge de son plus ancien élément figurent au tableau de bord.

D3 — Le tableau de bord de portefeuille

Le tableau de bord est un fichier HTML autonome, ouvrable localement sans aucune dépendance externe, sans serveur, hors ligne. Il matérialise trois choses et trois seulement. Le registre, d'abord : la table unique des objets pilotés, portant pour chacun son identifiant, son taxon, sa désignation, son statut, sa posture TELOS, son stade dominant, son échéance, son propriétaire, sa consommation de tampon et sa dernière décision. C'est la source unique de vérité de l'axe Statut. Le panier d'indicateurs, ensuite : neuf signaux avec leurs seuils. Le journal des décisions et l'état du sas, enfin : les dernières décisions datées et motivées.

Les règles de tenue sont peu nombreuses et strictes. Le registre vit dans le tableau de bord et nulle part ailleurs ; toute copie dans un autre fichier viole la résidence unique. Le tableau de bord est mis à jour au dernier geste du cycle et à chaque changement de statut — jamais « plus tard ». Tout changement de statut est daté et motivé en une ligne dans le journal des décisions, et cette trace constitue, à elle seule, l'historique décisionnel du portefeuille. Le fichier devrait être versionné, ce qui fournit gratuitement l'audit des évolutions.

D4 — Le dossier de projet et son contexte

Chaque feuille terminale de l'arbre des sujets est un dossier de projet. À l'intérieur, les artefacts portent le gabarit de nommage : la date ISO, le chiffre de stade de 0 à 9, la désignation, la version. Le chiffre a la même signification dans tous les projets :

0 PILOTAGE · 1 OBSERVATION · 2 BORDURES · 3 RESSOURCES · 4 ÉVALUATION
5 CONCEPTION · 6 INSTALLATION · 7 MAINTENANCE · 8 RÉCOLTE · 9 DISPOSITION

Le tri alphabétique du dossier restitue ainsi, sans aucun outil, la chronologie ; et le chiffre dit la fonction de chaque artefact, indépendamment de sa date, car l'ordre des stades est logique, non chronologique. Un artefact d'observation peut être produit après un artefact d'installation ; sa position dans la grille exprime ce qu'il fait, non quand il a été fait.

Chaque dossier de projet actif contient un document de contexte, conforme au modèle fourni : identité et mission, positionnement, stack et outillage, architecture du processus central, économie et coûts, chronologie des décisions structurantes, état courant, conventions de collaboration avec l'assistant. C'est la mémoire distillée du projet — courte, exacte, à jour ; tout ce qui n'a plus cours migre dans sa chronologie. Au sens de SOBRE, ce document est la couche L2 de la pile d'instruction : il porte ce que l'assistant ne peut pas découvrir seul — décisions arbitraires, chausse-trapes, vocabulaire maison, interdits — et rien de ce qu'il peut inférer de l'environnement.

D5 — Le classeur de pilotage

Chaque projet actif d'une certaine ampleur — posture prédictive, produit ou hybride, ou tout projet à échéance contractuelle — devrait disposer d'un classeur de pilotage : rétro-planning ancré sur le jalon final, suivi KPI hebdomadaire, matrice de décision à trois mois (continuer, basculer, arrêter — les critères d'abandon écrits noir sur blanc), backlog unique priorisé, prospection, runbook d'incidents, plan de continuité, checklist de non-régression, changelog.

La répartition des responsabilités entre le tableau de bord, le contexte, le classeur et le dossier est l'orthogonalité appliquée au pilotage lui-même :

6. Le cycle en cinq gestes

Le cycle est l'usage minimaliste de la méthode. Le premier geste se pratique au fil de l'eau ; les quatre autres, en séance groupée — la revue hebdomadaire, trente à soixante minutes.

①  DÉPOSER          tout entre par le sas, sans réfléchir
②  FAIRE ANALYSER   l'assistant propose : coordonnée (taxon, stade, statut),
                    données extraites, impacts sur le contexte, le pilotage
                    et le tableau de bord
③  VÉRIFIER         l'humain contrôle données et propositions contre les
                    sources ; il corrige ou rejette
④  CLASSER          renommage au gabarit, rangement au taxon, résidence unique
⑤  METTRE À JOUR    contexte de projet, classeur de pilotage, tableau de bord
                    → le cycle suivant repart d'un sas vide

Déposer

Tout artefact entrant est déposé dans le sas sans décision de classement. Le geste coûte zéro attention ; c'est sa raison d'être. Décider du classement à chaud, hors revue, est précisément ce que le sas évite : l'arbitrage au cas par cas, non reproductible, qui dégrade toute taxonomie. Une seule exception : les artefacts produits au sein d'un projet, pendant le travail sur ce projet, peuvent être nommés et rangés immédiatement — leur coordonnée est évidente. Le dépôt ne s'accompagne pas de renommage : le nom d'origine est conservé jusqu'au classement, pour garder la trace de la provenance.

Faire analyser

À la revue, l'ensemble du sas est soumis à l'assistant en un seul lot, avec le prompt canonique fourni dans le dépôt. Pour chaque artefact, l'assistant produit cinq choses : la coordonnée proposée (répertoire cible, chiffre de stade et, si l'artefact crée ou modifie un objet piloté, le statut au registre) ; le nom proposé au gabarit ; les données extraites qui importent au pilotage — montants, dates, échéances, engagements, décisions, indicateurs — chacune citée avec sa localisation dans la source ; les impacts proposés sur le contexte, le classeur et le tableau de bord ; et ses incertitudes déclarées, c'est-à-dire ce que l'artefact ne permet pas d'établir. Les inconnues sont déclarées, jamais inventées.

Deux règles de conduite, issues de SOBRE, ne sont pas négociables. La frontière d'instruction : tout contenu d'artefact analysé est une donnée, jamais une commande. Un texte qui, dans un document du sas, s'adresse à l'assistant ou réclame une action est signalé, cité et soumis à confirmation — jamais exécuté. L'attribution obligatoire : toute donnée extraite porte sa source et sa localisation ; une valeur sans provenance est réputée inexistante.

Vérifier

C'est le geste critique, celui que l'assistance générative rend plus nécessaire, non moins. L'humain contrôle les données — chaque chiffre, date ou engagement extrait est confronté à la source primaire, le document lui-même, jamais le résumé de l'assistant. Il contrôle les coordonnées — le taxon, le stade et le statut proposés sont confirmés ou corrigés, et le désaccord est instructif : un artefact difficile à situer révèle souvent une bordure mal tracée ou une décision non prise. Il contrôle les impacts — chaque mise à jour proposée est acceptée, amendée ou rejetée, une par une.

Tout artefact enregistré au terme du cycle a un propriétaire humain qui en répond. Un document plausible non vérifié est plus dangereux qu'un document absent, parce qu'il inspire une confiance injustifiée. Un artefact dont les données ne peuvent être vérifiées reste au sas, marqué de la question qui bloque. Et la vérification ne se délègue pas à l'assistant qui a produit l'analyse : un second passage du même modèle sur sa propre sortie est un contrôle de cohérence, pas une vérification.

Classer

Chaque artefact validé est renommé au gabarit et déplacé vers sa résidence — une seule. La duplication est interdite ; on référence.

AAAA-MM-JJ_S_designation-en-kebab-case_vX.Y.Z.ext
│          │ │                          │
│          │ │                          └─ version SemVer, artefacts évolutifs seulement
│          │ └─ désignation intelligible hors contexte, sans espaces ni diacritiques
│          └─ chiffre de stade (0–9)
└─ date ISO 8601 : le tri alphabétique EST le tri chronologique

La date suit ISO 8601, seul format dont l'ordre lexicographique coïncide avec l'ordre chronologique. Le jeu de caractères se limite aux lettres, chiffres, point, tiret et souligné — sans espaces ni diacritiques, dont la normalisation Unicode compromet la portabilité. La version ne s'applique qu'aux artefacts évolutifs ; les artefacts d'enregistrement — relevés, factures, comptes rendus — n'en portent pas. Rien ne se supprime : un artefact périmé passe au stade 9 et, le cas échéant, au statut ARCHIVÉ. Un artefact invoqué par un second projet monte alors — et alors seulement — en ressources : la transversalité se constate, elle ne s'anticipe pas. L'assistant peut exécuter mécaniquement les renommages et déplacements validés ; l'humain a validé la liste complète avant exécution.

Mettre à jour

Le cycle se termine par la mise à jour des trois artefacts vivants, dans cet ordre. Le contexte de projet, uniquement si un changement structurant a eu lieu — décision, incident, bascule de version, leçon actée ; les changements non structurants n'y entrent pas, et c'est ce qui le maintient court. Le classeur de pilotage : tâches créées ou soldées, KPI de la semaine, changelog, incidents versés au runbook. Le tableau de bord, enfin : registre, indicateurs, journal des décisions, état du sas. La mise à jour du tableau de bord est le dernier geste de la revue ; il photographie l'état de sortie. La revue n'est pas close tant que le tableau de bord ne reflète pas les décisions prises pendant la revue. Un tableau de bord en retard d'une semaine est un tableau de bord faux.

7. La vie d'un projet, de l'intention à la récolte

Le cycle traite le flux quotidien. Reste la vie d'un objet piloté, de sa naissance à sa sortie du registre. PRAXIS compresse ici TELOS à l'échelle entrepreneuriale ; pour tout projet dépassant cette échelle — équipe étendue, enjeu contractuel lourd, régulation forte —, TELOS s'applique en entier.

L'intention. Toute idée de projet entre au registre en statut INTENTION — formulée, non engagée, non dotée. Une intention ne coûte qu'une ligne. Les intentions sont revues à la revue mensuelle ; la plupart y meurent, et c'est leur fonction : mourir à l'état de ligne plutôt qu'à l'état de chantier.

L'engagement. Le passage d'INTENTION à ACTIF est un acte formel, jamais un glissement. Il produit, avant tout travail de réalisation, un dossier d'engagement tenant sur deux pages. D'abord l'énoncé de bénéfice aux six critères de TELOS : attribution (qui retire quel avantage), mesurabilité (quelle grandeur, quel instrument), ligne de base effectivement mesurée, profil temporel, chaîne causale maillon par maillon, coût d'opportunité (à quoi renonce-t-on). Ensuite les critères d'abandon, écrits avant l'engagement : seuils de dérive, hypothèses dont l'invalidation rend le projet caduc, date-butoir de démonstration. Trois lignes datées suffisent ; leur existence neutralise l'escalade d'engagement mieux que toute lucidité future, parce qu'elles séparent le jugement du moment de l'engagement de celui du moment de l'arrêt. Puis le diagnostic de contingence à six axes — nouveauté, technologie, complexité, rythme, régulation, irréversibilité, notés de 1 à 4 —, conduit en dix minutes, qui détermine la posture (prédictive, itérative, produit, exploratoire, hybride) et les dispositions que tout axe noté 3 ou plus impose. Enfin l'estimation en intervalle, jamais un chiffre unique, confrontée à au moins un comparable : un projet passé de la base interne de classes de référence ou, à défaut, une distribution sectorielle publique en majorant l'incertitude. Le financement, en temps comme en argent, devrait être séquencé par tranches conditionnées à la levée d'incertitudes nommées.

Le flux. Quatre dispositions gouvernent l'exécution. La limite d'encours : au plus deux projets actifs par personne — c'est la disposition au meilleur rendement de toute la méthode, à coût nul et effet immédiat, que le tableau de bord affiche et que la revue hebdomadaire fait respecter. Le tampon unique agrégé : les tâches sont estimées à leur durée médiane, sans marge individuelle, et la marge retirée est concentrée en un tampon de fin de projet dont le taux de consommation, rapporté à l'avancement, est l'indicateur de santé central. Le suivi d'âge : l'âge du plus ancien élément en cours et l'âge des dépendances externes non résolues sont des indicateurs avancés plus fiables que tout pourcentage d'avancement déclaré. Les petits lots : réduire la taille des lots jusqu'au point où le coût de transaction devient limitant, puis attaquer ce coût par l'automatisation.

Les jalons. À chaque jalon, et au minimum à la revue mensuelle, le projet répond aux questions de la double boucle : les hypothèses de l'engagement tiennent-elles encore ? Le diagnostic à six axes a-t-il évolué ? Un critère d'abandon est-il atteint ou approché ? Et le test de l'observateur extérieur : en ignorant tout l'investissement déjà consenti, engagerions-nous ce projet aujourd'hui ? Corriger l'écart au plan sans jamais interroger le plan est le mode de défaillance dominant de la discipline ; la revue mensuelle est calendarisée précisément pour forcer cette interrogation, car son déclencheur naturel — l'échec manifeste — arrive toujours trop tard. Un projet interrompu passe en SUSPENDU avec une condition de reprise vérifiable et une date de réexamen ; à défaut de reprise à cette date, il passe en ARCHIVÉ. Il n'existe pas de suspension sans condition : c'est la définition du projet zombie.

La sortie. Un projet quittant ACTIF entre soit en DOMAINE — il est exploité, donc doté d'une procédure d'exploitation formelle ; un domaine sans procédure est un projet inachevé qui se présente comme achevé — soit en ARCHIVÉ. Aucune troisième issue n'est admise. L'absence de cette règle est la cause principale de l'engorgement des systèmes de gestion de projet : les projets n'y meurent pas, ils cessent d'être mentionnés. La checklist de sortie comprend le versement de l'écart estimé/réalisé dans la base de classes de référence — la seule opération qui améliore structurellement la capacité prévisionnelle de la structure.

La récolte. À six mois puis à douze mois après la sortie, la grandeur définie dans l'énoncé de bénéfice est mesurée avec l'instrument prévu, comparée à la ligne de base et au profil attendu, et l'écart est consigné au tableau de bord. Ces deux rendez-vous sont inscrits au calendrier au moment de la sortie, avec un responsable nommé. Un projet dont les bénéfices n'ont pas été mesurés n'est pas terminé ; il est seulement arrêté.

8. Les cadences

Chaque instance est justifiée par la décision qu'elle produit ; une instance qui ne produit aucune décision est supprimée. À l'échelle entrepreneuriale, une seule est obligatoire : la revue hebdomadaire.

Trois règles de tenue. La revue hebdomadaire a un créneau fixe au calendrier : une revue qu'on replanifie chaque semaine est une revue qui disparaît. La revue mensuelle porte exclusivement sur la validité des hypothèses, jamais sur l'avancement — l'avancement appartient à l'hebdomadaire, et mélanger les deux enferme dans la boucle simple. La révision du référentiel de classement ne se fait pas au fil de l'eau : les évolutions sont groupées, versionnées et actées à la revue trimestrielle, parce qu'une classification est une infrastructure dont la valeur tient à sa stabilité.

L'ordre du jour de la revue hebdomadaire tient en cinq temps. Le sas, dix à vingt minutes : analyse du lot par l'assistant, vérification contre les sources, validation des coordonnées, renommage et rangement, avec pour objectif un sas vide ou des éléments restants marqués de la question qui bloque. Le flux, cinq à dix minutes : encours par personne, âge du plus ancien élément, dépendances externes et leur âge, blocages à lever. Les projets actifs, dix à quinze minutes : consommation de tampon contre avancement, KPI saisis, tâches soldées et créées — sans aucune discussion d'hypothèses, qui est l'affaire de la revue mensuelle. Les décisions, cinq minutes : chaque décision prise est consignée au journal, avec sa date et son motif en une ligne. Le tableau de bord, cinq minutes : registre, indicateurs, entrée d'historique de la semaine. La revue est close quand le tableau de bord est à jour.

9. Collaborer avec l'assistant sans lui abandonner le jugement

La répartition des rôles est nette. L'assistant analyse le sas et extrait les données avec attribution ; l'humain vérifie contre les sources primaires. L'assistant propose coordonnées, noms et impacts ; l'humain arbitre, corrige, valide. L'assistant exécute les renommages et déplacements validés ; l'humain a validé la liste complète avant exécution. L'assistant prépare les mises à jour du contexte, du classeur et du tableau de bord ; l'humain relit, enregistre et porte la responsabilité de chaque artefact. L'assistant génère des hypothèses, des comparables, des brouillons ; l'humain décide, signe, tranche les arbitrages de valeur.

Cette répartition n'est pas un partage des tâches à parts égales : elle alloue l'effort humain là où il est devenu rare — la vérification et la mise à jour, et les décisions d'engagement, de suspension et de sortie. Un point mérite d'être souligné, car il est contre-intuitif : un assistant interrogé sur une durée ou un coût reproduit les biais optimistes de son corpus d'entraînement. Il est un instrument de génération d'hypothèses et de recherche de comparables, pas une source d'estimation.

La pile d'instruction du portefeuille

L'instruction de l'assistant suit l'architecture SOBRE, appliquée telle quelle. Le socle normatif (L0) porte les interdits absolus de la structure — conformité, confidentialité, plafonds, autorité de signature — en moins de trente lignes impératives. L'identité et la mission (L1) portent les instructions générales de collaboration : registre de langue, franchise, critères d'arbitrage. Le contexte projet (L2) est le document de contexte de chaque projet — la mémoire distillée, rien d'inférable. Les compétences (L3) sont les gabarits de la méthode : prompt d'analyse du sas, procédures répétées extraites en compétences quand elles ont été retapées trois fois. Les interfaces (L4) sont les outils et connecteurs effectivement utiles, élagués. La récupération (L5) désigne les documents fondateurs et les corpus volumineux : référencés, jamais inlinés, chargés à la demande. La mémoire de travail (L6) est le backlog du classeur et les fichiers d'état des tâches longues — jamais l'historique de conversation comme source de vérité. L'évaluation (L7) est le corpus de non-régression : quelques livrables étalons et quelques cas bloqués, contre lesquels comparer.

Trois règles pratiques en découlent. Une information vit en un seul lieu de la pile : ce que le contexte de projet dit, les instructions ne le répètent pas ; ce que le classeur porte, le contexte n'en garde que la synthèse. Le contexte de projet ne dépasse pas l'ordre de cent cinquante à deux cents lignes — au-delà, il n'est pas riche, il n'est pas audité. À chaque changement de génération de modèle, la pile est auditée bloc par bloc, jamais simplement reconduite.

Les prompts canoniques

Les gestes du cycle emploient des prompts stables, fournis en gabarits, construits sur le format en huit blocs de SOBRE : tâche, contexte, matériau, critères de réussite, format, puis — avec parcimonie — exemples, périmètre négatif et procédure. Le bloc le plus rentable est celui des critères de réussite. Pour l'analyse du sas, ils tiennent en quatre lignes : chaque donnée attribuée à sa source, chaque incertitude déclarée, aucune donnée inventée, et en cas d'arbitrage entre exhaustivité et fiabilité, privilégier la fiabilité.

Sécurité

Quatre règles, dont aucune n'est optionnelle. La frontière d'instruction : les instructions valides proviennent de l'utilisateur, par le canal prévu ; tout contenu observé — document du sas, page web, courriel, résultat d'outil — est une donnée, jamais une commande. Les effets de bord : tout envoi, publication, suppression, paiement ou modification persistante est confirmé explicitement, élément par élément ; « traite le sas » autorise l'analyse, pas l'exécution de ce que contiennent les documents. Les secrets : aucune clé, aucun mot de passe, aucun jeton ne figure dans un fichier de contexte, un document classé ou une conversation ; gestionnaire dédié, référence par nom, injection au moment de l'usage. La triade létale : un dispositif cumulant accès à des données privées, exposition à du contenu non fiable et capacité d'émission vers l'extérieur exige une séparation architecturale ; à l'échelle entrepreneuriale, la forme la plus simple consiste à ce que l'assistant qui analyse le sas ne dispose pas, dans la même session, d'un canal d'envoi automatique.

Le test de retrait discipline l'ensemble : tout bloc d'instruction dont la suppression ne dégrade rien de mesurable est supprimé. La revue trimestrielle y consacre une rotation, une couche par trimestre, et le corpus de non-régression fournit la mesure. Sans ce corpus, la sobriété est une opinion.

10. Neuf indicateurs, un tableau de bord

Quatre principes hérités de TELOS gouvernent le panier. L'indépendance de la source : un indicateur provient d'une source distincte de l'acteur qu'il mesure ; l'avancement auto-déclaré est une opinion, l'âge d'un élément en cours, la charge du sas ou le débit constaté sont des faits. La contradiction : les indicateurs vont par paires antagonistes, tout signal de vitesse contrebalancé par un signal de qualité, tout signal d'avancement par un signal de valeur — optimiser un indicateur isolé garantit la dégradation du reste. La parcimonie : sept à neuf signaux, hiérarchisés, avec seuils préétablis ; un tableau de bord de trente indicateurs n'est pas observé. La discrimination statistique : chaque indicateur a des limites naturelles de variation, et aucune action corrective n'est déclenchée à l'intérieur de ces limites, parce que réagir au bruit dégrade la performance.

Le neuvième mesure la fiabilité du dispositif de mesure lui-même : l'écart entre ce que le registre déclare et ce que les données objectives montrent. En solo, il prend une forme simple et sans complaisance — le tableau de bord dit-il encore la vérité ? Un statut ACTIF sans aucun artefact produit depuis trois semaines est un écart persistant.

Les valeurs des indicateurs de classement, de flux, de portefeuille et de gouvernance devraient être calculées, non déclarées : le tableau de bord les dérive du registre, du journal et des dates qu'il porte. Seuls les indicateurs de tampon et de bénéfice sont saisis depuis leurs sources. Chaque indicateur s'affiche avec son seuil et son état — nominal, à surveiller, alerte — et l'ergonomie recherchée est celle d'un poste de pilotage : l'état d'ensemble en dix secondes, le détail en un geste. L'historique hebdomadaire est conservé dans le fichier même, une entrée par revue, ce qui rend visibles les tendances. La tendance importe plus que la valeur.

11. Quatorze pièges, et où ils se voient

Les trois documents fondateurs recensent chacun leurs pièges — vingt-six pour TELOS, dix anti-modèles pour le RCUP, un catalogue d'anti-patrons pour SOBRE. PRAXIS en retient quatorze, les plus fréquents à l'échelle entrepreneuriale, et donne pour chacun le signal au tableau de bord, c'est-à-dire l'endroit où le piège se voit.

Le tableau se lit en revue. Il vaut par sa dernière colonne : un piège que l'on ne peut pas voir est un piège que l'on ne corrige pas.

12. Trois niveaux d'adoption, et ce qui ne se comprime jamais

Une adoption partielle doit rester cohérente. PRAXIS définit trois niveaux cumulatifs.

Le niveau 1, solo minimal, demande une demi-journée d'entrée. L'arborescence n'exprime que le sujet, les dates sont au format ISO dans les noms, aucun doublon. Un sas, purgé chaque semaine. Le tableau de bord tient le registre : tout objet piloté a un statut, et la sortie n'a que deux issues. La revue hebdomadaire, au créneau fixe, exécute les gestes ② à ⑤. Deux projets actifs par personne. Pour tout engagement, un énoncé de bénéfice d'une demi-page avec ligne de base mesurée, et des critères d'abandon en trois lignes datées. Un registre des décisions, tenu sans exception. Un contexte de projet par projet actif, court et à jour.

Le niveau 2, standard, ajoute la grille de stades dans les noms, le classeur de pilotage pour les projets qui le justifient, le diagnostic de contingence à l'engagement et à chaque jalon, la revue mensuelle de double boucle, le tampon unique et son suivi, et les sept premiers indicateurs.

Le niveau 3, complet, ajoute le gabarit de nommage intégral avec versionnage, les neuf indicateurs avec historique, le prémortem avant tout engagement majeur, la vérification des bénéfices à six et douze mois versée aux classes de référence, la revue trimestrielle avec révision groupée du référentiel et audit de la pile d'instruction, et le corpus de non-régression pour l'assistant.

Une mise en œuvre déclare son niveau ; toute dérogation à une exigence du niveau déclaré est écrite et datée dans le dossier de pilotage. Et cinq exigences ne se compriment jamais, quel que soit le niveau : la ligne de base mesurée avant engagement ; les critères d'abandon écrits avant l'engagement ; la règle des deux issues ; la purge du sas ; la vérification humaine des données extraites par l'assistant.

13. Limites et modes de défaillance

L'intégrité d'une méthode se juge à ce qu'elle dit de ses propres faiblesses. PRAXIS en nomme cinq.

Le coût de la double tenue. La méthode maintient trois artefacts vivants — contexte, classeur, tableau de bord — et le risque est leur divergence silencieuse. La parade est structurelle, chaque information n'ayant qu'un lieu, et rituelle, le dernier geste les mettant à jour ensemble dans le même quart d'heure. Si la divergence s'installe malgré cela, c'est que des informations sont dupliquées : il faut auditer la répartition, pas redoubler d'efforts.

Le théâtre méthodologique. Toute méthode explicite peut être exécutée formellement sans être pratiquée. Le test de falsification, hérité de TELOS, est sans appel : si aucune revue des douze derniers mois n'a produit une décision de réorientation, d'abandon ou d'archivage, le dispositif ne fonctionne pas — il est appliqué sans être opérant. Le registre des décisions rend ce test vérifiable en trente secondes.

La dépendance à l'assistant. Le cycle confie l'analyse à l'assistant ; si la vérification humaine s'affaiblit — par confiance acquise, par fatigue, par volume —, le système enregistre des données plausibles et fausses, et le tableau de bord ment avec assurance. La contre-mesure est le maintien délibéré de la vérification comme geste actif, confrontation aux sources, jamais relecture de confort. L'indice de divergence est le détecteur de dernière ligne.

Le biais conservateur. Comme le référentiel de classement dont elle hérite, PRAXIS excelle à insérer le nouveau dans l'existant et sert mal la rupture. Un projet exploratoire supporte mal le cérémonial : on lui applique le niveau 1 seul, avec un jalon d'abandon daté, et rien de plus.

La limite irréductible. Aucune méthode ne compense un objectif faux ou une incitation perverse maintenue. PRAXIS révèle ces situations — par les critères d'abandon, l'indice de divergence et la mesure des bénéfices — plus vite qu'elle ne les corrige.

14. Commencer en quinze minutes

L'installation tient en quatre étapes. Créer l'arborescence : un sas, un dossier de pilotage, un répertoire par marque, un dossier de ressources. Ouvrir le tableau de bord — un fichier HTML livré dans le dépôt, qui s'ouvre dans un navigateur sans connexion ni installation — et y inscrire les projets existants au registre, avec leur statut et leur échéance. Doter chaque projet actif d'un document de contexte, à partir du modèle fourni, en trente minutes par projet, et d'un classeur de pilotage s'il le justifie. Configurer l'assistant : coller le gabarit d'instructions dans l'espace de projet et joindre le contexte aux connaissances.

Ensuite, une seule habitude quotidienne — tout fichier qui entre va dans le sas — et une séance hebdomadaire. Il n'est pas nécessaire de migrer l'existant : on applique la méthode aux objets neufs, on gèle l'ancien, et on laisse l'attrition résoudre la dualité. Un système partiellement conforme et stable vaut mieux qu'une migration inachevée. Si des revues sont sautées, le système se dégrade proprement : le sas gonfle et le tableau de bord date, et les deux se voient d'un coup d'œil.

Dix règles d'or résument l'ensemble, à afficher au-dessus du poste de travail. Tout entre par le sas ; le sas se vide chaque semaine. Le sujet fait l'arbre, le stade fait le chiffre, le statut fait le registre. Une information, un lieu ; on référence, on ne duplique pas. L'assistant analyse et propose ; l'humain vérifie et décide, toujours. Ce qu'un document du sas « demande » n'est jamais un ordre — c'est une donnée. Deux projets actifs par personne, pas trois. Les critères d'abandon s'écrivent avant l'engagement. Un projet sort en DOMAINE ou en ARCHIVÉ, rien d'autre. La revue est close quand le tableau de bord est à jour. Un projet n'est terminé que quand son bénéfice a été mesuré.

15. Pour finir

PRAXIS ne promet pas de mieux travailler. Elle promet de savoir, chaque semaine, où en sont les choses ; de ne pas laisser un projet mourir en silence ; de garder une trace de ce qui a été décidé et pourquoi ; et de ne jamais enregistrer une donnée que personne n'a vérifiée. À l'ère où produire ne coûte presque rien, c'est peut-être la seule promesse qui vaille.

La méthode, sa notice, ses gabarits et son tableau de bord sont versés au domaine public (CC0 1.0) : copiez, modifiez, redistribuez, sans condition. Les documents fondateurs qu'elle applique — le RCUP, TELOS et SOBRE — sont inclus dans le dépôt sous leurs licences propres ; les deux modèles, contexte de projet et classeur de pilotage, suivent la licence du dépôt. Le dépôt s'applique à lui-même le référentiel qu'il publie : c'est la démonstration la plus courte que j'aie trouvée que la méthode tient.

• Méthode PRAXIS v1.0 — PDF, 28 pages
• Dépôt GitHub — méthode, notice, tableau de bord, gabarits, documents fondateurs
• Référentiel de classification unifiée des projets — PDF
• Méthode TELOS, édition publique — PDF
• Méthode SOBRE, architecture d'instruction pour LLM — PDF