Base de connaissance — Méthodologie PROJECT & Atelier IA

Une part considérable du savoir technique circule aujourd'hui en vidéo — démonstrations d'équipement, formations internes, revues de conception filmées, webinaires fournisseurs. Et ce savoir est, en pratique, illisible.

Coller le lien d'une vidéo dans un assistant IA vous rend, au mieux, une transcription — qui manque tout ce qui est à l'écran : les schémas, les plans, le code, la courbe qu'on commente sans la décrire. Or dans une vidéo technique, l'essentiel est très souvent à l'image.

regarder-video répond à ce manque. L'outil prend une URL ou un fichier local et produit un brouillon en Markdown : transcription horodatée d'un côté, captures d'images aux changements de plan de l'autre. Vous obtenez à la fois les mots et les visuels, prêts à être relus, annotés, classés.

Trois principes de conception, et ils ne sont pas négociables.

Primitives inspectables — environ deux cents lignes, lisibles d'un bout à l'autre. L'outil n'invente rien : il orchestre deux briques éprouvées, yt-dlp et ffmpeg. Aucune magie, donc aucune surprise.

Local d'abord, souverain par défaut — rien ne quitte votre machine. La transcription de secours, quand la vidéo n'a pas de sous-titres, tourne elle aussi en local. C'est ce qui rend l'outil utilisable sur un contenu confidentiel : une revue de conception interne ne part pas chez un tiers.

Humain dans la boucle — l'outil produit un brouillon. Il n'ingère rien. Il ne décide pas de ce qui entre dans votre base de connaissance : vous relisez, vous coupez, vous classez. La machine prépare la matière ; le jugement reste où il doit être.

Le code est public, sous licence ouverte : github.com/QInternational/regarder-video. Il n'y a rien à vendre ici — c'est un outil de praticien, publié parce qu'il sert, et inspectable parce que c'est la seule façon d'en répondre.

Un projet peut être livré sans être transféré.

Les livrables sont remis, la documentation est complète, les formations ont eu lieu — et pourtant, trois mois plus tard, le client appelle en urgence. Pas parce que quelque chose est cassé. Parce qu'il ne sait pas quoi faire seul.

Trois niveaux.

Documenter — on dit. Ça s'oublie.

Former — on montre. Ça fonctionne dans les conditions de la formation.

Impliquer — les opérateurs ont participé aux tests, les techniciens ont suivi les phases critiques, les décideurs ont été associés aux choix structurants. Le savoir ne leur est pas transmis, il s'est construit avec eux.

Le vrai signe qu'un transfert a réussi : le client ne vous appelle plus en mode urgence. Il vous appelle quand il veut aller plus loin.

La relation passe de réactive à proactive. Du prestataire qu'on appelle quand ça casse au partenaire qu'on consulte quand on veut avancer.

Un projet qui laisse le client plus capable qu'avant ne ferme pas une relation. Il en ouvre une nouvelle — où vous n'êtes plus nécessaire, mais choisi.

La recette finale n'est pas un moment de vérification. C'est un moment de confirmation. Si on y découvre des écarts, c'est qu'on a raté quelque chose avant.

Le check permanent : des points de contrôle réguliers, à fréquence courte, pour maintenir la calibration. Vérifier que ce qu'on construit correspond toujours à ce que le client attend — pas ce qu'il a signé au départ, ce qu'il attend aujourd'hui.

Deming a construit son cycle sur Plan, Do, Check, Act. Le "Check" n'est pas une phase finale — c'est le battement régulier du projet. Sans lui, le Plan devient une fiction.

On revient au sacro-saint "Speak with Data" comme règle de pilotage. Les intentions ne se gèrent pas. Les faits, si.

Transformer les "on pense que ça va bien" en mesures. L'avancement réel vs. le planning. Les réserves consommées vs. le budget. Les demandes de modification hors périmètre qui s'accumulent. Ces données ne mentent pas. Les opinions peuvent se tromper de bonne foi.

La recette sans surprise n'est pas un coup de chance. C'est le résultat d'un check conduit tout au long du projet — pas seulement à la fin.

Grace Hopper a programmé les premiers compilateurs dans les années 50. Dans la marine américaine. Dans une organisation où la hiérarchie n'est pas un détail. Elle savait de quoi elle parlait.

Dans les projets, l'attentisme est mortel. Le chef de projet qui attend le feu vert, la validation, le consensus, ne prend pas de risques. Il en crée un, plus grave : il délègue sa responsabilité vers le haut — et bloque le projet au passage. Coûts, délais, jalons manqués. Tout dérive.

L'initiative en gestion de projet n'est pas une question de caractère. C'est une question de calcul. Quand le coût de ne pas agir dépasse le coût d'agir et de réparer — il faut agir. L'autorisation parfaite n'arrivera jamais avant la deadline.

Le contre-poids est réel : cette posture ne signifie pas ignorer les contraintes contractuelles ni court-circuiter les décisions structurelles. Mais dans les interstices — là où les processus ne couvrent pas, là où la situation évolue plus vite que le circuit de décision — l'initiative est une compétence. Pas une faute.

Un chef de projet qui attend toujours l'autorisation n'est pas un pilote. C'est un greffier.

Dans chaque équipe projet, il y a un profil rare. Celui qui avance pour de vrai — qui assume, qui se mouille, qui prend des décisions quand personne d'autre ne veut en prendre. Qui absorbe l'incertitude sans la propager.

Ce qui use ce profil n'est jamais l'intensité du travail. C'est le frottement inutile. La procédure qui sert à contrôler plutôt qu'à produire. La critique venue de celui qui n'a pas agi, sur le travail de celui qui a agi.

À chaque friction inutile, quelque chose se consume. Silencieusement. Et un jour, il rend son tablier.

Et là, on découvre ce qu'il emportait avec lui. Sa compétence, sa mémoire du projet, son réseau. Le turnover invisible fonctionne selon une loi simple : les meilleurs partent en premier. Parce qu'ils ont des options.

Protéger ceux qui font, ce n'est pas couvrir leurs erreurs. C'est dégager leur espace d'action. Absorber le frottement à leur place.

Signaler que celui qui avance est défendu — pas malgré ses prises de risque, mais à cause d'elles.

C'est le premier acte de leadership. Pas le dernier.

Un chef de projet ne fait pas le même travail sur tous les projets. Pas parce que les méthodes changent. Mais parce que le regard change — et que tout découle de là.

Mission de redressement — cartographie d'impact. Le projet existe. Il dérape. On commence par une grille : qu'est-ce qui saigne, et à quelle profondeur ? Financier, organisationnel, commercial, contractuel. On stoppe l'hémorragie, on remet sous contrôle.

Dans mon expérience : des équipes abattues, des projets à l'arrêt. La première question était toujours — qu'est-ce qui ne tourne pas, et pourquoi ?

Mission de structuration — cartographie de besoin. Le projet n'existe pas encore. Il n'y a rien à diagnostiquer — il y a quelque chose à concevoir. Les invariants techniques, les étapes de mise sur marché, les preuves à construire.

Dans mon expérience : un nouveau marché, une industrialisation à définir depuis zéro. La grille n'avait pas les mêmes colonnes.

Ce que j'ai appris : identifier le type avant d'agir.

Un chef de projet qui arrive sur un redressement avec une posture de construction va chercher à organiser ce qui doit d'abord être stoppé.

Un chef de projet qui arrive sur une structuration avec une posture de diagnostic va chercher des problèmes là où il n'y en a pas encore — et en créer.

Mêmes méthodes. Deux cartes. Un seul choix à faire correctement dès le premier jour.

Archimède sort de son bain en courant, nu, dans les rues de Syracuse. Il crie "Eureka !" — "j'ai trouvé" en grec. Un passant étranger comprend une demande de serviette. Même mot. Deux univers.

Dans les projets internationaux, c'est exactement ce qui se passe avec les exigences. Le danger n'est pas dans les désaccords explicites — ceux-là, on les voit. Le danger réel, c'est le faux accord : deux parties qui acquiescent, qui signent, qui valident — et qui n'ont pas compris la même chose.

Trois dimensions culturelles qui parasitent la capture des requis sans qu'on s'en rende compte.

Le rapport à l'autorité — dans certaines cultures, on ne dit pas non au client ni au chef de projet. On dit oui, et on espère que la réalité finira par s'adapter.

Le rapport à l'implicite — un livrable "fini" en France inclut la documentation. En Angleterre, parfois non. Aux États-Unis, c'est ce qui est écrit dans le SOW, ni plus ni moins.

Le rapport au temps — une deadline "ambitieuse" est un objectif à atteindre pour certains, un point de départ de négociation pour d'autres. Ces deux interprétations peuvent coexister dans la même réunion sans que personne ne le remarque.

J'ai travaillé sur des projets de tests industriels en Inde, en Corée, aux États-Unis et en Europe — pour le même client, les mêmes normes, les mêmes livrables contractuels. Les frictions venaient toujours du même endroit : quelqu'un avait compris quelque chose de différent, sans que le désaccord soit jamais visible dans les échanges.

Ce que j'ai appris à faire : ne jamais demander "avez-vous compris ?" La réponse sera toujours oui. Demander à la place : "Pouvez-vous me dire ce que vous avez compris ?" Les deux ou trois phrases qui suivent valent plus que dix réunions de validation.

La reformulation n'est pas une technique de communication. C'est un outil de capture des exigences réelles, par-dessus le filtre culturel.

Un accord signé n'est pas une compréhension partagée.

La démotivation d'une équipe projet n'est pas souvent ce qu'on croit.

Ce n'est pas la charge de travail, en général. Ce n'est pas le salaire, la plupart du temps.

C'est quelque chose de plus discret, de plus profond — et de plus dévastateur : l'incohérence entre le discours et les actes.

Chaque fois que le chef de projet prend un engagement et ne le tient pas, quelque chose se passe dans l'équipe. Un enregistrement silencieux. Personne ne dit rien — mais tout le monde a noté.

La deuxième fois, la note est confirmée. À la troisième, la confiance commence à se fragmenter.

Et une équipe dont la confiance est fragmentée ne travaille plus ensemble — elle travaille en parallèle, chacun pour soi, avec une partie de son énergie consacrée à se protéger plutôt qu'à avancer. C'est l'énergie gaspillée qu'on ne mesure jamais.

L'exemplarité n'est pas une vertu morale. Ce n'est pas non plus une affaire de leadership "inspirant". C'est un mécanisme opérationnel, simple et brutal.

"On fait ce qu'on dit" : les engagements pris, même mineurs, tenus systématiquement. La réunion du lundi à 9h qui commence à 9h. Le retour promis pour jeudi qui arrive jeudi. Le point de difficulté signalé en réunion qui trouve une réponse concrète — pas un "on verra".

"On dit ce qu'on fait" : la transparence sur les décisions, y compris les mauvaises nouvelles. Quand le planning glisse, l'équipe est la première informée, pas la dernière. Quand une décision vient de la direction, elle est transmise sans filtre — pas reformulée pour ménager les susceptibilités.

J'ai travaillé avec des équipes qui produisaient des résultats remarquables dans des conditions difficiles. Et d'autres, bien dotées en ressources et en outils, qui tournaient à vide — dégradant silencieusement l'objectif "bon du premier coup" en "bon du prochain coup". La différence n'était jamais dans les outils.

Elle était dans la réponse à une question simple que chaque membre de l'équipe se pose, souvent sans se l'avouer : "Est-ce que je peux compter sur la parole de ce pilote ?"

Quand la réponse est oui, quelque chose se libère. L'énergie qui servait à se méfier, à surveiller, à se couvrir — elle peut aller au projet.

La plupart des équipes projet pensent au Transfer à la fin du projet. C'est trop tard.

Le Transfer — la documentation, la passation, l'ouverture aux services — ne se prépare pas en clôture. Il se conçoit en cadrage. Ce qu'on n'a pas prévu de transmettre, on ne le transmettra pas.

Deux livrables que je construis dès le départ, sur chaque projet.

L'ossature de la documentation client — celle que les gens vont vraiment utiliser. Une documentation pensée pour ceux qui vont vivre avec le système : ses opérateurs, ses techniciens de maintenance, ses futurs prestataires. Partagée en phase étude. Mise à jour au long du projet. En phase avec la réalité terrain.

La meilleure documentation est celle que le client s'approprie — qu'il utilise encore 3 ans après. Ce n'est pas un critère esthétique — c'est un critère de survie du projet après sa clôture.

L'ouverture au business des services. Le projet se termine. La relation, elle, peut continuer. Pièces de rechange, contrats de maintenance, formations opérateurs, évolutions futures. Cette porte ne s'ouvre que si elle a été dessinée dans les plans dès le début. Un projet qui ne pense pas à ses suites ferme lui-même cette porte — et transforme une relation de confiance en relation tendue, d'urgence.

Livrer un projet sans préparer les services, c'est construire une maison sans remettre les clés.

Le Transfer bien conduit ne clôt pas une relation. Il en ouvre une nouvelle — plus stable, plus équilibrée, plus rentable pour les deux parties.

Un projet qui prépare son propre Transfer dès le cadrage produit deux choses que les autres ne produisent pas : un client autonome — et une porte commerciale ouverte.

Sur chaque projet, il y a un moment redouté : la recette. Le client arrive. Il regarde. Il a une opinion. Et cette opinion n'est pas celle que vous attendiez.

Pas parce que le livrable est mauvais. Parce que personne n'a défini ce que "bon" signifiait — pas pour lui, avec ses mots, dans son contexte.

La recette sans protocole, c'est un procès sans règles de procédure. Chacun arrive avec ses propres critères implicites. Le désaccord n'est pas un accident — il est structurel.

C'est là qu'intervient la phase C de la méthodologie PROJECT. Pas pour créer une check-list de plus à cocher côté prestataire. Pour concevoir un processus de vérification qui guide le client dans sa participation.

Il y a une confusion fréquente sur le mot "idiot-proof". On l'entend comme "simplifié pour les incompétents". Ce n'est pas ça. Idiot-proof signifie : conçu pour que l'erreur soit impossible — pour que la bonne participation devienne le chemin naturel.

Appliqué à la recette : donner au client les outils pour surligner les délivrables contractuels, formuler ses observations et modifications, les objectiver, les hiérarchiser. Le rendre actif et précis — pas passif et frustré.

La recette devient ici une concrétisation du contrat. Ce qui est dedans, on le valide. Ce qui est hors périmètre, on l'identifie — et on ouvre la discussion sur une modification rémunérée. Pas de mauvaise surprise des deux côtés.

Le client ne sait pas toujours ce qu'il veut. Mais il sait reconnaître ce qu'il obtient. Encore faut-il lui donner les mots pour le dire.

Sans ces mots, il dit "ça ne me convient pas". Et vous ne pouvez pas corriger ce que vous ne comprenez pas. Avec ces mots, il dit "sur le point 3 de la spécification, le comportement observé diffère du comportement attendu pour les raisons suivantes." Et là, le dialogue devient possible.

Il y a un effet secondaire que j'ai appris à valoriser autant que le résultat direct : le client qui a participé activement à la validation s'approprie le résultat. Il ne le remet pas en cause trois mois plus tard. Il l'a co-construit.

La recette bien conduite ne sert pas seulement à valider un livrable. Elle sert à fermer un chapitre — proprement, sans séquelles.

Héraclite parlait de la nature du changement. Nous allons nous centrer ici sur la nature de l'exécution.

Un projet est un organisme vivant. Son sang, c'est le mouvement — les tâches qui se complètent, les décisions qui tombent, les jalons qui passent. Le mouvement n'est pas une option. C'est la condition de vie du projet.

Un ralentissement est une alerte. Quelque chose obstrue et doit être identifié immédiatement. Un arrêt est un étouffement. Le projet ne respire plus.

Un chef de projet qui accepte l'immobilité accepte la mort lente de son projet.

Le danger n'est jamais spectaculaire au départ. Il commence par une tâche en retard qu'on ne signale pas. Par une décision qu'on reporte — "ce n'est pas le bon moment". Par une réunion décalée une fois, puis deux. Par un silence de trois jours côté client.

Chaque micro-arrêt est un signal. Ignoré, il devient un blocage. Le blocage devient une crise.

Ce n'est pas le jalon manqué qui tue un projet. C'est l'habitude d'accepter l'immobilité.

En 2017, j'ai rejoint un client qui souffrait de plusieurs projets à l'arrêt. Pas de décision formelle de les stopper — juste un progressif enlisement. Les équipes attendaient. Les clients s'impatientaient. Les coûts couraient.

La première action : remettre du mouvement. Pas nécessairement dans la bonne direction — d'abord avancer. Dégager les blocages. Créer de l'élan.

C'est une contre-intuition que j'ai apprise sur le terrain : parfois, avancer dans la mauvaise direction vaut mieux que l'immobilité. Parce que le mouvement révèle les obstacles — là où l'arrêt les cache. Parce que l'élan attire les décisions que l'immobilité repousse.

La phase E de la méthodologie PROJECT, ce n'est pas seulement "faire avancer les tâches". C'est maintenir le flux.

Et le maintenir, ça commence par surveiller les bons signaux — pas seulement les jalons du plan. Le flux ralentit avant que le jalon soit officiellement en retard. Celui qui regarde le mouvement voit la crise venir. Celui qui regarde le plan la voit arriver trop tard.

Un bon chef de projet surveille le flux. Pas seulement les jalons.

Un projet ne patine presque jamais pour des raisons techniques. Il patine parce que personne n'a dit ce qui devait être dit.

Parce que la salle était confortable. Parce que le sujet était délicat. Parce qu'on a préféré une formulation qui ne froisse personne — et qui ne bouge rien non plus.

J'ai appris à nommer les choses. Pas pour choquer. Pas pour dominer. Pour que ça rentre, que ça reste, et que ça crée du mouvement.

"On n'avance pas dans le projet en gardant les mains dans son froc." "Un manager qui se cache derrière sa main ne guide pas." "Un projet n'est pas une réunion de vieilles dames qui prennent le thé."

(Ces formules ont été réajustées pour préserver la décence du post — mais vous en saisirez l'esprit.)

Ces formulations ne sont pas de la brutalité. Ce sont des marqueurs. Ils tracent une position sans ambiguïté. Ils créent la dissonance nécessaire pour que les gens entendent vraiment.

La dissonance n'est pas un problème de management. C'est un outil.

Le moment où on dit ce que personne ne voulait entendre est bref — souvent inconfortable. Mais c'est le seul moment où les choses bougent vraiment. Où les décisions tombent. Où les équipes se repositionnent.

Ce qu'on ne nomme pas reste flou. Ce qui reste flou sera interprété. Ce qui est interprété sera disputé. (Les lecteurs de la phase R de la série reconnaîtront le fil.)

Patton avait raison sur un point essentiel : ce n'est pas la vulgarité qui marque. C'est la précision. Le mot qui atteint. Le registre qui tranche avec l'ordinaire.

"It has to be eloquent profanity."

Tyson a raison. Mais la réponse n'est pas de ne pas avoir de plan. C'est de préparer le plan pour quand le coup arrive.

Sur chaque projet, il y a un moment où ça déraille. Pas toujours de façon spectaculaire. Parfois juste un retard qui s'accumule. Une décision que personne ne prend. Un interlocuteur qui ne répond plus. Un problème technique qui bloque tout.

Et là, la question n'est pas : "qu'est-ce qui se passe ?" La question est : "qui décide quoi, maintenant ?"

Si vous n'avez pas la réponse en 30 secondes, vous avez un problème d'organisation.

La phase O de la méthodologie PROJECT, c'est précisément ça : construire la mécanique avant d'en avoir besoin.

Pas l'organigramme. Pas la liste des responsabilités copiée du contrat. La mécanique réelle — qui fait quoi, dans quel délai, avec quelles informations, et surtout : qui escalade vers qui quand c'est dégradé.

P dit qui. R dit quoi. O dit comment. Si O n'est pas posé, P et R restent des intentions.

Concrètement, la phase O définit trois niveaux :

Le fonctionnement normal — qui pilote, qui rend compte, à quelle fréquence, dans quel format.

Le fonctionnement dégradé — quels signaux déclenchent une alerte, qui est notifié, dans quel délai.

Le circuit de crise — qui décide, qui a l'autorité, qui peut débloquer des ressources.

Ces trois niveaux se définissent au démarrage, quand tout va bien. Pas le jour où ça casse.

Un outil simple pour y voir clair : la matrice urgence / criticité. Quatre quadrants, quatre traitements différents. La task force ne se déploie que dans un seul — mais elle doit être identifiée, constituée et prête dès le premier jour du projet si le risque le justifie.

La matrice ne se remplit pas en réunion de crise. Elle se prépare en phase O.

Ce qu'on ne définit pas à froid, on l'improvise sous pression. Et l'improvisation sous pression, ça coûte : en temps, en relation client, en énergie d'équipe.

La meilleure réunion de crise est celle qu'on n'a pas eu à improviser.

Pendant des années, j'ai vu des chefs de projet traiter les plaintes clients comme des attaques. Posture défensive. Escalade. Réunions de crise. Avocats, parfois. Et à la fin : une relation abîmée, un projet ralenti, et un besoin qui n'avait toujours pas été capturé.

Le problème n'est pas le client qui râle. Le problème, c'est ce qu'on n'avait pas su écrire au départ.

Quand un client se plaint, il ne se plaint pas — il dit ce qu'il voulait vraiment. Ce que la réunion de kick-off n'avait pas capturé. Ce que le contrat avait laissé dans l'implicite. Ce que lui-même n'avait pas su formuler en phase R.

Ce n'est pas une attaque. C'est une mise à jour des exigences.

La transition qui change tout : sortir du mode défensif pour entrer dans le mode pilotage.

Concrètement : écrire la plainte. La reformuler comme un besoin. La comparer au contrat. Identifier l'écart. L'intégrer au registre.

Le client qui râle devient, sans le savoir, un co-pilote. Sa réclamation devient une donnée. La friction devient de l'information.

"La plainte est le requis que personne n'avait osé écrire."

La première itération de discussion autour de la phase R de la méthodologie PROJECT posait : "ce qui n'est pas écrit sera interprété". Celle-ci pose : ce qui n'a pas été dit au départ sera dit sous forme de plainte. Écoutez-la.

C'est ceux qui savent. C'est ceux qui veulent. C'est ceux qui ont intérêt. Ces trois cercles ne coïncident presque jamais avec l'organigramme.

La vraie équipe projet est plus large que la liste du kick-off. Elle inclut l'expert technique qu'on n'a pas officiellement impliqué. Le manager dont l'équipe sera impactée sans qu'on lui ait demandé son avis. Le client final que personne n'a pensé à consulter. Le directeur financier absent de la réunion — mais dont le visa sera nécessaire dans 3 mois.

Si ces gens ne sont pas touchés, ils ne disparaissent pas. Ils deviennent spectateurs frustrés. Puis acteurs de nuisance.

La réponse : une matrice de communication. Pas un tableau de plus. Un engagement structuré envers chaque partie prenante.

Qui reçoit quoi. À quelle fréquence. Dans quel sens. Pas pour informer — pour impliquer.

On commence par le bonjour quotidien — tel que la Phase J nous l'a enseigné. On continue par une communication délibérée, avec un niveau de détail adapté à chacun. On sollicite les avis. On les intègre quand ils sont pertinents — et on le dit. Ce geste simple maintient le flux.

Parce qu'une organisation est changeante. La personne ignorée et frustrée aujourd'hui peut se retrouver à un poste impactant demain. L'allié qu'on n'a pas cultivé peut devenir l'obstacle qu'on n'avait pas prévu.

Rendre tout le monde — tout-le-monde — sinon acteur, au moins spectateur engagé.

Voilà ce que j'ai vu trop souvent. Le dernier jalon de paiement est reçu. Le projet est "terminé". Les équipes passent à autre chose. Personne ne se retourne.

Pas de bilan. Pas de documentation. Pas de passation formelle. Les méthodes qui ont fonctionné restent dans la tête de ceux qui partent. Les erreurs qui ont coûté cher n'alimentent aucune mémoire collective. Dans 18 mois, sur le prochain projet, le même service refera les mêmes erreurs — au même coût.

La précipitation l'emportant sur la vitesse.

En entreprise, cette faiblesse est tolérée. Les ressources restent joignables. On peut toujours appeler. Le transfer informel remplace le transfer structuré.

Pour un manager de transition, cette option n'existe pas. Le jour où je pars, je pars vraiment. Ce que je n'ai pas transmis est perdu. Ce que l'équipe ne sait pas faire seule, elle ne saura pas faire.

Le Transfer n'est pas la dernière case à cocher. C'est l'acte qui valide tout ce qui précède.

Un projet bien transféré continue à vivre après moi. Un projet mal transféré régresse — et efface le travail accompli.

Laisser une trace, tout au long du projet. Et s'assurer que le flambeau sera repris. Pas pour moi. Pour le bien de mon client.

Exécuter un projet, c'est transformer des décisions en actions. Vérifier un projet, c'est s'assurer que les actions sont tenues. Les deux se jouent dans le même point d'échange : la réunion d'avancement.

On y vient avec le compte-rendu prêt à 80%. Pas après la réunion. Avant.

Parce qu'on veut transmettre la maîtrise. Parce qu'on veut surligner les points critiques. Parce que c'est un fantastique support de présentation : il trace les avancements, les points ouverts, les décisions à prendre. Il propose des tâches — avec un Qui et un Quand.

Et, on le présente. On le challenge. On l'affine. Puis on le valide — ensemble.

Ce mécanisme fait trois choses simultanément. Il donne une direction — sans imposer. Il crée un espace de contradiction — sans perdre le fil. Il génère de la responsabilisation — sans pression artificielle.

Parce qu'une tâche écrite avec ton nom, lue devant tes pairs et validée par toi, n'est plus une suggestion. C'est un engagement. Personnel. Et visible.

E et C : l'endroit où le projet avance — ou s'enlise. La différence tient souvent à la qualité d'une réunion hebdomadaire.

Sur chaque mission, chaque matin, je dis bonjour à tout le monde avant de commencer quoi que ce soit. Tout le monde. Pas l'équipe. Tout-le-monde.

Pas un email de groupe ou un message sur Teams. Physiquement. En se levant. En passant devant chaque poste. En échangeant. Un salut. Une prise de nouvelles. Une blague.

En 30 secondes, je sais tout ce que le planning ne me dira pas. Qui est tendu. Qui est fatigué. Qui a un problème qu'il n'a pas encore formulé. Qui a besoin d'être reconnu ce matin.

Ce rituel n'est pas de la politesse. C'est la santé du projet.

Désamorcer un conflit naissant avant qu'il devienne un blocage. Détecter la démotivation avant qu'elle devienne un départ. Donner le sourire — et le recevoir en retour.

Il y a quelque chose de profond dans ce mécanisme : quand on donne de l'attention sincère le matin, les gens en rendent — en information, en effort, en coopération.

Les psychologues appellent ça le biais de réciprocité. Les chefs de projet appellent ça une équipe qui tourne.

J — Jell : le moment où un groupe de personnes devient une équipe. Pas sur un organigramme. Ensemble — face aux aléas, aux événements, aux coups de grisou aussi.

Chacun doit pouvoir se dire : je ne suis pas seul.

À toutes les équipes qui m'ont laissé partager ces matins-là — merci.

Il existe un dicton chez les chefs de projet : "Ça chie toujours aux interfaces." Là où deux périmètres se touchent sans se définir. Là où chacun suppose que l'autre a compris. Là où la marge disparaît sans qu'on l'ait vu venir.

Un contrat ne couvre jamais 100% du travail attendu. Ce n'est pas une faille. C'est une réalité. La question : qui en sera l'acteur — et qui en sera la victime ?

2022 - 20 projets repris simultanément. Dans chacun : des zones grises exploitées. Des prestations hors périmètre exécutées de bonne foi. Des modifications acceptées verbalement, jamais formalisées. Résultat : marge en chute, cashflow sous pression.

Jean-Daniel Ygolinski, chez GE Thermodyn, me l'avait dit : "Maîtrise ton contrat au mieux — et prépare-toi à gérer ce qu'il ne couvre pas."

La réponse à cette problématique : un registre des écarts, ouvert dès J1. Chaque modification. Chaque effort non compensé. Chaque prestation hors périmètre. Date. Initiative de qui. Bénéfice de qui. Coût estimé.

Cet outil a deux usages selon la posture du client. Si le client joue le jeu : la relation devient collaborative. On négocie des avenants sur des faits, pas sur des impressions. S'il ne joue pas le jeu : le registre devient la justification d'un point d'arrêt. "Voici les 8 modifications non compensées. Nous ne poursuivons pas sans avenant."

2023 - Nouvelle mission. Registre ouvert dès la première réunion — avec le client. Résultat : jalons respectés à 100%. Programme de recherche conjoint créé.

Phase R, ce n'est pas rédiger un cahier des charges. C'est décider que les zones grises d'un contrat ne seront pas des pertes subies.

En arrivant sur un projet, je veux voir son planning. Pas pour le suivre. Pour voir ce qu'il dit de ceux qui l'ont fait.

Un planning que personne ne comprend n'existe pas. Un planning sans ressources nommées ne sera pas respecté. Un planning sans jalons intermédiaires n'a pas de signaux d'alerte. Un planning sans mention des livrables occulte le cashflow.

2022 : 20 projets repris simultanément. Dans la moitié : pas de planning à jour. Dans l'autre moitié : des plannings que personne ne regardait plus.

Première semaine : un planning par projet. Réaliste, pas optimiste. Ressources nommées — qui fait quoi, à quelle date, avec quelle disponibilité réelle. Partagé avec le client. Engagé des deux côtés.

Parce qu'un planning partagé n'est pas un document. C'est un engagement.

"On fait ce qu'on dit et on dit ce qu'on fait."

C'est là que la confiance se construit — ou se perd. Pas dans les réunions. Pas dans les présentations. Dans l'écart entre ce qui était prévu et ce qui a été livré.

Phase O, ce n'est pas faire un Gantt. C'est décider collectivement de ce qui sera tenu — et par qui.

La fin d'une mission est un bon moment pour souffler et prendre le temps de se retourner vers l'arrière. Et après plus de 20 ans de métier, je vois en me retournant ceux qui m'ont construit.

Mon regard s'arrête sur les collègues de GE Thermodyn — équipes, chefs de projet, techniciens, commerciaux — qui ont partagé leurs méthodes, leurs erreurs, leur expérience.

Et ceux qui ont pris le rôle de mentor...

Christian Schmutz, bien sûr, mais aussi :

Jean-Daniel Ygolinski, chez GE Thermodyn, dont la leçon ne m'a pas quitté : "Maîtrise ton contrat et prépare-toi aux conséquences de ce qu'il ne couvre pas."

Gérard Guilet, qui débloquait les échanges avec les clients avec : "Aidez-nous à vous aider." — et qui m'a montré qu'une relation contractuelle peut être collaborative si on le décide.

Christian Charollais, dont le motto "On fait ce qu'on dit et on dit ce qu'on fait" ne m'a jamais quitté.

Trois phrases. Vingt ans de boussole. GE Thermodyn a été mon école de chef de projet.

Ce que j'ai appris là-bas, je ne l'ai pas appris dans un livre. Je l'ai appris en regardant faire, en me trompant, en étant repris, en recommençant.

Ce que je partage aujourd'hui à travers la méthodologie PROJECT n'est pas mon travail. C'est le leur — que je me charge maintenant à transmettre.

Merci à tous.

2017 : Un projet bloqué depuis 3 ans. Pas de problème technique. Pas de problème budgétaire. Un problème de personnes.

En prenant mon poste, j'ai regardé les gens. Qui avait intérêt à ce que ça avance ? Qui avait intérêt à ce que ça reste en l'état ? Qui portait une responsabilité sans légitimité — ou l'inverse ?

Ces trois questions m'ont donné la vraie feuille de route.

Jusqu'au constat : des profils côté client bloquaient structurellement — pas par mauvaise volonté, par position. Il a fallu près de 6 mois pour les neutraliser et permettre aux éléments moteurs de revenir en responsabilité.

Le client a intégré l'équipe — pas comme valideur. Comme acteur.

Le projet a pu redémarrer parce qu'on avait changé la configuration humaine. Planning défini. Moyens mobilisés. Objectifs tenus. Cashflow rétabli. Relations contractuelles renforcées.

2023 Nouvelle mission. Je n'ai pas attendu que le problème se pose. Dès le jour 1 : le client entre dans l'équipe projet. Résultat : jalons respectés à 100% et sécurisation des Marges.

Méthodologie PROJECT — Phase P : People. Ce n'est pas les RH. Ce n'est pas l'organigramme. C'est la question que trop peu posent avant de démarrer :