Process Tech
Le processus d'un projet, de la signature à la clôture
Une même façon de travailler pour tout le monde, adossée à une mémoire qui survit à celui qui la tient. Les couloirs disent quel outil a la main, le processus avance de gauche à droite. Le trait plein marque ce qui tourne déjà chez l'un ou chez l'autre, le pointillé ce qui a été décidé mais reste à construire. Cliquer une étape pour la lire en détail.
Reconstitué depuis la revue technique « Revue tech — Chartrons », 16 septembre 2026, 59 minutes — transcription Fireflies.
La transcription a attribué les 59 minutes à un seul locuteur. Rien de ce document n'est donc nominatif : on a gardé les décisions, pas qui les a prononcées.
- existant
- à construire
- jalon
- i point à trancher
- le schéma défile vers la droite →
Périmètre et vocabulaire
Le processus commence à la signature. L'avant-vente — qualification, chiffrage, proposition — est déjà couverte ailleurs et n'entre pas ici. Il s'arrête à la clôture du projet.
Un client peut porter plusieurs projets ; un projet vaut pour un périmètre, pas pour un compte — deux chantiers chez le même client sont deux projets. Sous le projet : des tâches et des sous-tâches. Les lots ont été abandonnés, ils ajoutaient un niveau que personne ne tenait.
Pourquoi maintenant
Le déclencheur n'est pas théorique : une période d'absences arrive, et un projet doit pouvoir être repris par quelqu'un qui n'était pas dessus. Tout le reste en découle — si la mémoire du projet vit dans la tête de celui qui le mène, elle part avec lui.
Deuxième principe, posé d'entrée et tenu toute la réunion : on part du besoin, pas de l'outil. Le partage ci-dessous n'a de sens que parce que le rôle a été nommé avant l'outil qui le porte.
Qui tient quoi
Ce qui compte n'est pas la liste, c'est la frontière : deux outils qui portent la même chose finissent par diverger, et on ne sait plus lequel dit vrai.
| Outil | Ce qu'il porte | Ce qui n'y va pas |
|---|---|---|
| GitHub | La référence du projet : le code, et les fichiers Markdown internes — contexte, avancement, décisions, comptes rendus, pièges. Un dépôt par projet, privé à l'organisation, accès désigné. | Les livrables clients |
| Google Drive | Ce qui sort chez le client et ce qu'il envoie : PDF, Excel, présentations, pièces contractuelles. | La mémoire de travail |
| ProdVision | Les tâches et le reste à faire — y compris sur projets internes et hors projet, pour remplacer les listes personnelles. | Les documents |
| LastPass | Mots de passe, comptes partagés, accès. Un dossier par projet. | Le reste |
| HubSpot | L'amont : deal gagné, devis et ses lignes, cadrage, échanges commerciaux logués. | La vie du projet après signature |
| Claude Cowork | Le projet partagé de l'avant-vente : ce qui s'est discuté avec le client avant la signature. Comment en ressortir la matière facilement reste à trouver. | La mémoire du projet |
| Fireflies | Les comptes rendus d'appels, rangés par dossier client, le projet nommé dans le titre de la réunion. | — |
| VS Code | Le poste de travail, Claude Code dedans. Un seul environnement, pour que skills et configurations se partagent. | — |
| Notion | À trancher. Porte aujourd'hui des dossiers de projet entiers, faute de mieux. | — |
Le démarrage
Une commande unique — le client, la nature du projet — et le projet est monté : dossier local, dépôt distant, contexte rassemblé, skills de la stack installés. Le modèle assumé est celui de la checklist avant décollage : une liste finie d'informations sans lesquelles un projet ne peut pas commencer. Ce qui manque n'est pas deviné, il est demandé.
Deux garde-fous ont été posés dans la foulée, parce que c'est l'étape qui coûte le plus cher. Le premier : borner le périmètre — sur un gros projet dont on ne pilote qu'un lot, charger tout le reste ne fait que parasiter le travail. Le second : chercher par dossier plutôt que balayer — le dossier du client dans Fireflies, le dossier du projet dans la boîte mail. Sinon le contexte est mangé avant qu'on ait écrit une ligne.
La journée
Le matin, un brief programmé balaie Slack, les mails, les comptes rendus d'appels, le calendrier et les tâches, puis crée ou met à jour ce qui a bougé. Un fichier d'état retient la date du dernier passage pour ne pas repasser deux fois sur la même chose. Il tourne déjà.
Pendant la journée, une conversation par sujet — le pilotage d'un côté, la production de l'autre. Quatre conversations en parallèle sur le même projet se marchent dessus. Quand le contexte est plein, il est déversé dans les fichiers du projet et un message de reprise est produit pour la session suivante : le compactage automatique perd trop.
Le soir, la clôture : la mémoire du projet est mise à jour et poussée sur le dépôt, et si ça n'a pas été fait, l'outil le réclame. C'est cette étape, et pas le schéma, qui rend un projet reprenable par un autre le lendemain matin.
Deux règles d'écriture
Markdown tant que c'est interne. Moins de jetons à lire, un format que tout le monde relit et que n'importe quel agent comprend. Le PDF, l'Excel et la présentation sont des formats de livraison : ils vivent dans Drive.
Plusieurs fichiers plutôt qu'un. Un fichier de contexte unique finit par déborder et par être lu de travers. Contexte, avancement, pièges, configuration : séparés, et bornés en taille.
Ce qu'il reste à trancher
Ce qui reste à construire
Repris automatiquement des étapes en pointillé du schéma, pour que les deux ne puissent pas diverger.