Admin, orga, delivery : gérer un projet client avec l'IA

Fin mai, devant une centaine de freelances et de consultants, j’ai prononcé ASCII « assis ». Un participant m’a corrigée dans le chat. Je raconte cet épisode parce qu’il résume tout le sujet. J’ai travaillé huit ans dans l’IA, côté projets et organisations, jamais côté code. Tout mon travail consiste à prendre ma logique métier et à l’adapter pour qu’elle rentre dans des logiques d’ingénieur, en réutilisant les outils des codeurs sans forcément savoir ce qu’ils recouvrent, ni comment ils se prononcent. Parce que pour maîtriser un système IA, inutile de maîtriser le langage technique. Ce qui compte, c’est votre savoir-faire métier et le bon sens qui va avec, et votre capacité à l’expliciter à l’IA : c’est elle qui le transcrit en technique. Le vocabulaire suivra, ou ne suivra pas, et ça n’a aucune importance.

La session a duré deux heures ; j’en livre ici l’essentiel. Rien de ce qui suit n’est une théorie : c’est mon système réel, celui qui tourne pendant que j’écris ces lignes.

Un bon système est un système qu’on utilise

Pas un système parfait. Un système qu’on utilise. La distinction a l’air anodine, elle change tout : un système doit s’adapter à vous (votre activité, votre manière de travailler, même votre gestion de l’énergie), et pas l’inverse. Vous êtes expert de votre métier. Personne d’autre ne peut vous dire comment le faire.

Donc faites votre marché dans ce qui suit. Prenez ce qui vous parle, laissez le reste, et surtout adaptez. Chaque prompt que je donne est fait pour être modifié.

Deux mots de vocabulaire avant de démarrer :

• Le second cerveau : un dossier de fichiers texte (markdown), chez moi dans Obsidian, où vit tout mon contexte de travail : projets, clients, décisions, notes. C’est la matière que l’IA lit.
• Un skill (ou une commande) : un process documenté dans un fichier, que l’agent IA (Claude Code, OpenCode ou équivalent) exécute quand je l’appelle. /cr_reunion lance mon process de compte rendu, /facturation mon process de facturation.

Mon cadre tient en trois piliers : l’admin pour gagner du temps, l’orga pour gagner en clarté, le delivery pour gagner en qualité.

01 · Admin : gagner du temps

Un projet est un petit système

Un projet client a le même cycle de vie que votre organisation entière, en miniature : une initialisation, une vie, une clôture. J’en tire une conséquence simple : je duplique la structure de mon second cerveau à l’échelle de chaque projet. Un dossier documents (la matière reçue), un dossier notes (le travail intermédiaire), un dossier livrables, et des fichiers de référence.

Six fichiers qui évitent de repartir de zéro

C’est la fondation de tout le reste. Dans chaque projet :

• contexte.md : le client, l’enjeu, l’historique
• propale.md : ce qui a été vendu, exactement
• planning.md : le macro-planning et les jalons
• réunions.md : l’index des réunions
• arbitrages.md : l’index des décisions
• tâches.md : ce qui reste à faire

Ce sont des documents de référence, pas des documents de travail. Pour ceux qui viennent de la data : ce sont mes golden sources. Toutes mes commandes s’appuient dessus : le compte rendu vérifie la cohérence avec les arbitrages, la facturation lit la propale, le suivi lit le planning. Sans eux, chaque commande repartirait de zéro et re-scannerait tout le projet à chaque appel.

La bonne nouvelle : vous n’aurez presque jamais à remplir ces fichiers vous-même. Ma commande /new_project crée la structure et la peuple avec les transcriptions des calls d’avant-vente et de kick-off (n’importe quel note-taker fait l’affaire). Vous enregistrez les réunions, et ça se remplit tout seul.

Astuce au passage : quand je lance une commande, je la cible avec @nom-du-projet. /facturation @Dupont et l’IA va chercher directement le contexte, la propale et le planning du bon projet.

La logique wiki : des index, pas des fichiers géants

Ne mettez pas toutes vos réunions dans un seul fichier interminable. Faites comme Wikipédia : des pages courtes reliées entre elles, et des pages sommaires qui servent d’index. Ma page réunions.md n’est pas mes réunions, c’est le sommaire de mes réunions. Ma page arbitrages.md liste les décisions : chacune avec une date, un identifiant (« la décision T2 », c’est plus rapide que de réexpliquer), un type, un résumé, et un lien vers la réunion source.

Deux conséquences pratiques. Un : j’inscris cette logique dans les instructions générales de mon agent, et je la répète dans chaque commande (« toute note créée doit être référencée dans l’index correspondant »). Deux : je lâche prise sur l’emplacement physique des notes. Les sommaires sont pour l’IA, pas pour moi. Tant qu’ils sont bons, c’est elle qui s’y retrouve, et c’est elle qui doit s’y retrouver.

La clôture : tout nettoyer, sauf les arbitrages

En fin de projet, l’IA fait le ménage : elle supprime les notes de travail, condense les réunions, garde le contexte, la propale et le planning. Une seule exception, non négociable : les arbitrages restent tels quels. Imaginez qu’un client revienne un an plus tard sur une décision. Ce fichier-là, c’est votre mémoire et votre protection.

On vient de faire une grosse session et on est enfin arrivés à un résultat satisfaisant. Tu as vu comment je travaille et quelles sont les étapes de mon process. Transforme toute notre discussion en skill réutilisable : documente le déclencheur, les étapes, les fichiers concernés et les points où tu dois me demander validation.

02 · Orga : gagner en clarté

Le double CR : l’IA ne résume pas, elle interprète

C’est la pratique dont on m’a le plus parlé après la session. Une seule commande /cr_reunion, deux sorties :

• Un CR client, envoyable : les arbitrages, les actions, le ton adapté au client (j’ai travaillé pour une administration publique où il fallait des minutes formelles, le template s’adapte).
• Un CR interne, pour moi : les verbatims marquants du client, les points de tension détectés, les risques identifiés en croisant avec planning.md, les incohérences avec les décisions passées en croisant avec arbitrages.md.

Le CR client, n’importe quel outil de transcription sait à peu près le faire. Le CR interne, non. C’est là que l’IA change de nature : elle ne résume pas ce qui s’est dit, elle interprète ce qui s’est joué. Et le CR alimente automatiquement tâches.md avec les actions.

Pour calibrer le template, pas besoin d’imagination : donnez-lui vos dix derniers comptes rendus faits à la main.

Voici mes dix derniers comptes rendus de réunion. Analyse-les comme une banque d'exemples : structure, ton, niveau de détail, ce que je choisis de garder ou d'omettre. Puis adapte mon template de compte rendu pour qu'il produise exactement ce style.

À partir de cette transcription de réunion, produis deux comptes rendus.
1. Un CR client, envoyable : décisions prises, actions avec responsables et échéances, ton professionnel sobre.
2. Un CR interne : les verbatims marquants du client (ses mots exacts), les points de tension implicites, les risques que tu identifies en croisant avec planning.md, et toute incohérence avec les décisions déjà actées dans arbitrages.md.
Ajoute les nouvelles actions dans tâches.md et référence la réunion dans l'index réunions.md.

Capturer tous les canaux

Un client, ce n’est pas que des réunions : c’est aussi des mails, des WhatsApp, des appels. Cartographiez vos canaux, puis créez une commande qui les scanne tous et transforme ce qui traîne en tâches. Chez moi, un connecteur pour la messagerie (Beeper centralise WhatsApp, Telegram, LinkedIn) et un pour le mail (Himalaya).

Le gain réel n’est pas le temps, c’est la charge mentale : je n’ai plus à me rappeler qu’un message attend une réponse. La prochaine fois que je m’assois devant mon ordinateur, tout a été capturé.

Le hand-off : l’IA manage votre outil de tâches

Sur la gestion des tâches, deux modèles se valent. Soit le second cerveau est votre cockpit unique. Soit, c’est mon cas, vous gardez un logiciel spécialisé, surtout s’il est partagé avec une équipe ou un client. La clé est alors de séparer les deux niveaux : le macro (sur quoi je veux avancer cette semaine) vit dans le second cerveau ; le micro (« envoie le PDF ») vit dans le logiciel. Et je ne gère pas le micro moi-même : c’est l’IA qui manage mon logiciel de tâches.

Concrètement, la passation (je l’appelle le hand-off) se fait en quatre temps :

1. Une review dans le second cerveau pose les priorités. La mienne est tous les trois jours : j’ai essayé le quotidien, c’était trop pour moi. Adaptez.
2. Je demande à l’IA un brief détaillé, dans la peau d’un CEO qui briefe ses équipes. La commande pose des questions de clarification, repêche les tâches en retard oubliées, et me demande mon niveau d’énergie (deep focus ou création) pour me proposer un plan qui me plaît.
3. Ce brief part vers l’outil de tâches : en automatique s’il a un connecteur MCP (Notion, par exemple), en copier-coller dans son chatbot sinon. Et le copier-coller marche très bien.
4. Je relis ce que l’IA propose de déplacer ou de supprimer. La revue reste humaine.

Voici mes priorités de la semaine, issues de ma dernière review. Avant de faire quoi que ce soit : pose-moi tes questions de clarification, signale-moi les tâches en retard que j'aurais oubliées, et demande-moi mon niveau d'énergie (deep focus ou création).
Ensuite, rédige un brief très détaillé, comme un CEO qui briefe ses équipes, à destination de mon outil de gestion de tâches : réarrange les tâches existantes pour qu'elles correspondent à mes priorités, et liste explicitement celles que tu proposes de reporter ou de supprimer, pour que je valide.

La clôture qui impressionne : rapport, upsell, post-mortem

La fin de projet est le moment où tout ce qui précède paie. Comme tout est enregistré depuis le premier jour, la clôture devient un moment de valeur au lieu d’une corvée. Ma commande de clôture produit trois choses :

• Un rapport de clôture client : dates, jalons, rappel du contexte et de la finalité, livrables produits, arbitrages pris. C’est le document qu’on ne fait jamais parce qu’on n’a pas le temps. Mes clients adorent : « le projet a duré trois mois, on a tenu 57 réunions, voici les décisions structurantes ».
• Des perspectives d’upsell : l’IA scanne le projet et propose des suites. Un conseil si vos offres sont standardisées : bridez sa créativité pour que les suggestions se rattachent à vos offres existantes, sinon vous ne passerez jamais à l’échelle.
• Un post-mortem : ce qui a marché, ce qui a moins marché, ce que je ferais différemment, et les enseignements sont rapatriés dans ma base transverse, pas enterrés dans le dossier du projet. Je ne fais que reprendre ce que font les meilleurs, et je l’automatise.

On clôture ce projet. Dans l'ordre :
1. Nettoie : supprime les notes de travail intermédiaires, condense les notes de réunion, garde contexte.md, propale.md et planning.md. Ne touche pas à arbitrages.md : il reste tel quel.
2. Génère un rapport de clôture client : dates de début et de fin, grands jalons, paragraphe de rappel du contexte et de la finalité, livrables produits, arbitrages pris.
3. Propose des perspectives de suite pour ce client, en te limitant strictement à mes offres existantes décrites dans [fichier offres].
4. Rédige un post-mortem : ce qui a marché, ce qui a moins marché, ce que je devrais faire différemment. Rapatrie les enseignements réutilisables dans [fichier de capitalisation].
5. Archive le projet.

03 · Delivery : gagner en qualité

Les intérêts composés de la chaîne

On n’automatise pas un livrable de bout en bout. Même avec les meilleurs modèles, « écris-moi le rapport » produit un rapport médiocre. La bonne unité d’automatisation est plus petite : toute tâche contient implicitement quatre étapes, planifier, exécuter, relire, capitaliser. Mettez un peu d’IA à chaque étape, et les micro-gains se composent. Le résultat final est plusieurs fois meilleur que ce que vous auriez fait seul, et que ce que l’IA aurait fait seule.

Mon temps humain, je le passe sur le plan. C’est le nerf de la guerre : pour avoir une bonne solution, il faut d’abord bien poser le problème. Une fois le plan solide, l’exécution et la relecture sont déléguées, et je n’interviens que sur le résultat.

La review par sous-agents

Ma commande de review (adaptée du plugin Compound du média Every, je n’ai rien inventé) lance plusieurs sous-agents, chacun avec un angle : cohérence avec le contexte et la propale, respect du planning, fact-checking (pas de chiffres inventés), qualité éditoriale, alignement avec le brief. Le rapport de sortie est priorisé : critique, important, mineur. Si j’ai quatre heures, je passe tout en revue ; si j’en ai deux, je ne regarde que le critique et l’important. Le temps disponible fait partie du process.

Ne générez jamais un PowerPoint directement

L’astuce qui a le plus servi pendant la session. Les formats propriétaires (PowerPoint, Word) sont lourds à manipuler pour une IA : lents, coûteux en tokens, résultats décevants. Faites comme les designers avec leurs maquettes (lo-fi, mid-fi, hi-fi) :

1. ASCII : de simples croquis en texte brut dans un fichier markdown. « Propose-moi cinq layouts différents pour cette slide de benchmark » prend quelques secondes et ne coûte presque rien. Je choisis, on itère.
2. HTML : la version proche du rendu final, avec la charte : couleurs, logo, type de graphique.
3. Le format final : PowerPoint, PDF, Word, seulement à la toute fin, par simple demande de conversion. Pas besoin d’outil dédié.

Explorer en texte, itérer en HTML, convertir à la fin. Demander directement « génère-moi six slides PowerPoint » prendrait de longues minutes par essai, pour un résultat rarement satisfaisant.

Je veux créer une slide de [sujet, ex. benchmark de quatre solutions]. Propose-moi cinq layouts différents en format ASCII, dans un fichier markdown : varie les dispositions (tableau, cartes comparatives, matrice, jauges, score global). Une fois que j'aurai choisi, tu la passeras en HTML avec ma charte : [couleurs, logo, type de graphique].

Dernier détail de tuyauterie : en entrée, convertissez un maximum de documents en markdown (MarkItDown de Microsoft fait très bien le travail ; vérifiez à la main les fichiers qui contiennent des schémas). Mais gardez vos exemples de livrables au format original : l’IA doit voir à quoi ressemble le rendu attendu, les titres en bleu et les encadrés compris.

Adopter les skills des autres, sans se faire imposer leur cadre

Des skills partagés, il y en a partout, et le réflexe naturel est de les installer tels quels. Ne le faites jamais : vous vous retrouveriez à travailler dans le cadre de pensée de quelqu’un d’autre, et parfois vous avez déjà l’équivalent sous une autre forme. Mon protocole en trois temps :

1. L’IA analyse le skill à la lumière de mon contexte et de mes skills existants.
2. Elle me dit si ça vaut le coup, et comment l’adapter.
3. Elle m’interviewe pour le customiser.

Et pour départager plusieurs skills qui font la même chose, faites-les noter. Pour mon compte rendu de réunion, j’ai récupéré tous les skills de CR partagés sur GitHub, je les ai fait noter de 1 à 10 par l’IA, j’ai éliminé les moins bons et pillé les meilleurs pour améliorer le mien.

Voici un skill trouvé en ligne : [lien ou contenu]. D'après ce que tu sais de mon contexte, de ma manière de travailler et de mes skills existants :
1. Analyse-le et compare-le à ce que j'ai déjà : note chacun de 1 à 10, avec les avantages et les inconvénients.
2. Dis-moi s'il vaut le coup d'être installé, et ce qu'il faudrait adapter.
3. Si oui, interviewe-moi (questions une par une) pour le customiser à mon système avant de l'installer.

Par où commencer

Si vous partez de zéro, trois conseils, dans cet ordre.

S’inspirer des meilleurs. Les grands cabinets de conseil savent cartographier des process, c’est leur métier. Prenez un article ou un livre d’un expert de votre domaine, donnez-le à l’IA : « quels learnings, et quels process je peux en tirer ? ». Ça évite la page blanche sans vous imposer un cadre.

Cartographier grossièrement. Pas besoin d’un audit de trois semaines : « j’ai en gros quatre catégories d’activités » suffit pour démarrer avec une vision d’ensemble.

Construire au fur et à mesure. Il n’y a aucune injonction à tout planifier en amont. Mon système est le fruit de plusieurs mois : à chaque tâche non urgente, cinq minutes pour créer la commande à la volée, puis on itère. Les process sont faits pour évoluer : au début, le compte rendu de réunion, c’est juste « corrige les fautes », puis « structure », puis « rédige de bout en bout », puis « récupère la transcription, rédige et prépare l’envoi ».

Surtout, n’installez pas cinquante skills d’un coup. Avec l’IA, le goulot d’étranglement, c’est notre lenteur humaine, et c’est une bonne chose. Elle vous force à garder la maîtrise, à savoir pourquoi vous faites chaque chose et pourquoi vous la faites comme ça. Le jour où vous passez en pilote automatique, vous avez perdu la finalité.

Dernier point : le système est vivant. Votre activité évolue, vos process aussi. Une fois par trimestre, je passe mes skills en revue : lesquels mutualiser, lesquels supprimer, lesquels je n’utilise jamais (la plupart des agents savent vous dire quels skills vous avez réellement appelés le mois dernier).

Un bon système n’est pas un système parfait. C’est un système qu’on utilise, qu’on comprend, et qu’on fait évoluer. Faites votre marché.