1.3 Projet ou quotidien | Six traits et un test

Chapitre 1 · 1.3 Sommaire

1.3 Projet ou quotidien — six traits, et un test de deux minutes

Beaucoup de travail se fait mal parce qu'on lui applique la mauvaise organisation. On pilote en projet ce qui relève de l'exploitation, et l'on épuise une équipe pour un résultat que personne ne réceptionne ; ou l'on traite en routine ce qui était un projet, et l'on découvre en fin d'année que personne n'était responsable de le voir finir. Six traits suffisent à séparer les deux, et cette page les prend un par un. Le dernier — ce qu'on risque — est le plus utile, parce que les deux risques n'ont ni le même rythme ni le même remède. La page se termine par un test de trois questions, et surtout par la lecture du seul cas qui apprenne quelque chose : celui où les réponses ne sont pas toutes les mêmes.

Pourquoi la confusion coûte quelque chose

La question paraît scolaire. Elle ne l'est pas, parce que les deux erreurs possibles coûtent cher et ne coûtent pas la même chose.

Piloter en projet ce qui relève du quotidien produit une fatigue sans contrepartie. On installe des réunions, des jalons, un tableau de bord et des comptes rendus sur un travail qui, par nature, ne s'arrête pas. Au bout de quatre mois, plus personne ne vient aux réunions, le tableau de bord n'est plus tenu, et l'équipe a appris que ces dispositifs sont décoratifs. C'est le vrai dégât : vous avez consommé le crédit dont vous aurez besoin au projet suivant, celui où le dispositif aurait servi.

Traiter en routine ce qui était un projet produit l'inverse : rien ne se passe, longtemps. Le travail avance par à-coups entre deux urgences, personne n'est responsable de le voir finir, aucune date n'est engageante et aucune acceptation n'est prévue. On s'en aperçoit tard, en général au moment de facturer ou de rendre compte, et il ne reste alors ni budget ni disponibilité pour rattraper.

La bonne nouvelle est que le diagnostic est rapide. Six traits suffisent, et le test qui les résume tient en trois questions.

La fin

Un projet : il y a une date de fin, et un acte qui la constate. Le quotidien : il n'y a pas de fin, ça recommence lundi.

Il faut insister sur la seconde moitié, parce qu'elle disparaît presque toujours. Une date de fin sans acte qui la constate n'est pas une fin : c'est le jour où l'on a cessé de travailler. En France, cet acte a un nom, une définition légale et des effets lourds — c'est la réception, qui rend le solde exigible, transfère les risques et met en marche les délais des garanties. Un projet dont la fin n'est constatée par rien n'est pas seulement mal clos : il laisse ouvertes des questions d'argent et de responsabilité dont personne ne sait plus, deux ans plus tard, à quelle date elles ont commencé.

L'exploitation, à l'inverse, n'a pas d'acte de fin parce qu'elle n'en a pas besoin. On ne réceptionne pas la maintenance préventive. Ce qui la clôt, périodiquement, n'est pas un acte mais une période comptable — et une période n'engage personne.

Le résultat

Un projet : un livrable unique, qu'on n'a pas déjà fait dix fois. Le quotidien : un flux régulier, qui se mesure en cadence et en taux de rebut.

La différence qui compte n'est pas la nature de l'objet mais la façon dont on sait qu'il est bon. Un livrable unique se juge par comparaison avec ce qui a été commandé : on relit la spécification et on regarde. Un flux se juge par comparaison avec lui-même dans le temps : on regarde si la cadence tient et si le taux de rebut dérive. Ce sont deux appareils de mesure différents, et les échanger produit des indicateurs qui ne veulent rien dire.

C'est de là que vient un travers courant : mesurer un projet avec les indicateurs de l'atelier. Un taux d'occupation élevé ne dit rien de l'avancement d'un projet, il dit que les gens sont occupés — ce qu'ils sont toujours. Le chapitre 6, sur le suivi de l'avancement, revient longuement sur cette confusion, qui est la source d'à peu près tous les tableaux de bord inutiles.

L'équipe — le point où la PME française souffre le plus

Un projet : une équipe empruntée à d'autres services, pour un temps, et sans lien hiérarchique. Le quotidien : elle est là, elle reste, et elle rend compte à son chef de service.

C'est la ligne la plus lourde de conséquences, et celle qu'il faut se garder de présenter comme un dysfonctionnement à corriger. Ce n'est pas une anomalie : c'est le cas normal. Dans une entreprise de trente à deux cents personnes, il n'existe pas d'équipe projet dédiée, et il n'en existera pas. Les gens qui feront le travail appartiennent à des services qui les évaluent, fixent leurs priorités et les rappellent quand la production le demande. Vous ne les affectez pas, vous les demandez.

Trois conséquences suivent, et il vaut mieux les traiter comme des données du problème.

La première est que vos arbitrages ne vous appartiennent pas. Quand la panne du mardi emporte l'automaticien qui devait finir le paramétrage, ce n'est pas une trahison : c'est une décision rationnelle prise par un chef de service qui a ses propres comptes à rendre et qui n'a pas votre calendrier sous les yeux. La seule chose que vous puissiez faire est de rendre l'arbitrage visible et daté, pour que la personne qui le prend sache ce qu'il coûte. Un arbitrage écrit se discute ; un arbitrage implicite se subit.

La deuxième est que la disponibilité d'une personne ne se garantit pas par le droit du travail. Il faut le dire nettement, parce que l'idée inverse circule : aucun mécanisme du droit du travail français ne garantit qu'une personne nommée restera disponible pendant la durée d'un projet ou d'une garantie. Ce qui produit cet effet est contractuel : une clause de personnel clé dans le contrat entre les deux entreprises, qui nomme les individus, soumet toute substitution à un accord et à une qualification équivalente, et adosse le tout à une pénalité. C'est une clause de contrat commercial, jamais une règle sociale — et la confondre avec une protection légale conduit à ne rien écrire du tout.

La troisième touche au calendrier, et elle surprend souvent. Dans une entreprise d'au moins cinquante salariés, un projet qui introduit une nouvelle technologie ou constitue un aménagement important modifiant les conditions de travail doit faire l'objet d'une information et d'une consultation du comité social et économique, préalablement à la décision de mise en œuvre. Deux erreurs symétriques sont à éviter. La première consiste à croire que le comité doit donner son accord : le comité rend un avis ; il ne valide pas, il n'approuve pas, il n'autorise pas, et un avis défavorable n'empêche pas la décision. La seconde consiste à en déduire qu'on peut avancer sans s'en occuper. Ce serait une erreur de calendrier : le CSE ne peut pas dire non, mais il peut faire attendre. Dans ces entreprises de cinquante salariés et plus, le délai de consultation est d'un mois, porté à deux mois en cas d'expertise ; et il ne court pas de la convocation ni de la première réunion, mais de la communication des informations. Un dossier incomplet ne démarre donc rien du tout. Le chapitre 4, consacré à la conduite de l'équipe, développe ce point ; retenez ici qu'il se porte au cadrage du projet et non à la réunion où on le découvre.

Le chapitre 4 fera de cette ligne son sujet entier, parce que c'est le point de souffrance principal du lectorat de ce guide, et parce qu'il ne se règle ni par un organigramme ni par un discours sur la transversalité.

L'argent

Un projet : une enveloppe fermée, votée une fois, et suivie à part. Le quotidien : une ligne reconduite chaque année dans le budget courant.

La différence n'est pas comptable, elle est politique. Une enveloppe fermée oblige à arbitrer, parce qu'on voit ce qu'il reste. Une ligne reconduite permet de ne jamais arbitrer, parce qu'on la compare à l'an dernier plutôt qu'à un objectif. C'est pour cela qu'un projet financé sur le budget de fonctionnement d'un service échoue si souvent : non par manque d'argent, mais parce que rien n'oblige plus personne à choisir.

Un point technique mérite ici une place, parce qu'il concerne directement la manière de compter les gens. Une part importante des cadres français travaille au forfait annuel en jours, plafonné à 218 jours. Un salarié au forfait jours ne compte pas ses heures : dire qu'il est affecté à 30 % au projet n'a donc aucune base vérifiable. En revanche, dire que soixante de ses jours y passeront sur les 218 veut dire quelque chose, se contrôle et se compare. C'est la seule bonne raison, en France, de planifier en jours-personne plutôt qu'en pourcentages d'affectation, et elle vaut aussi bien pour votre budget que pour la conversation avec le chef de service qui vous prête quelqu'un.

Ce qui compte

Un projet : livrer conforme à ce qui a été commandé, et le faire constater. Le quotidien : tenir la production sans incident, semaine après semaine.

Les deux définitions du succès sont incompatibles, et c'est pourquoi la même personne ne peut pas être jugée sur les deux en même temps sans y perdre. Le responsable maintenance qui mène en plus un projet d'installation est évalué sur la disponibilité de ses machines ; le temps qu'il passe sur le projet dégrade son indicateur, et le temps qu'il passe sur ses machines fait glisser le projet. Il n'y a pas de solution élégante à cela, seulement une décision explicite à prendre en amont : quelle part de son temps est protégée, et qui l'a décidé.

Notez la seconde moitié du critère projet : et le faire constater. Livrer conforme ne suffit pas. Un livrable conforme que personne n'a accepté est, du point de vue du solde et des garanties, dans la même situation qu'un livrable non fourni. C'est une phrase désagréable et c'est la réalité de beaucoup de dossiers.

Ce qu'on risque — la ligne la plus utile

Un projet : que nul ne réceptionne, et que le solde reste dû sans qu'on sache à qui parler. Le quotidien : que la qualité dérive lentement, sans que personne ne le voie venir.

C'est la ligne qui mérite le plus de place, parce que les deux risques ne se ressemblent en rien — ni par leur rythme, ni par leur remède — et que la plupart des dispositifs de pilotage échouent en appliquant le remède de l'un au risque de l'autre.

Le risque de projet est brutal et daté. Il ne se dégrade pas progressivement : il se manifeste un jour précis, presque toujours à la fin, quand vous demandez la constatation et découvrez que la personne qui devait signer a changé de poste, que le service qui exploite ne s'estime pas compétent pour accepter, et que l'acheteur renvoie vers l'exploitant qui renvoie vers l'acheteur. Rien ne s'était dégradé la veille. Le risque était présent depuis le premier jour, simplement invisible, parce que rien dans le déroulement normal d'un projet n'oblige à vérifier qu'il existe quelqu'un pour dire oui à la fin.

Son remède est en conséquence de nature préventive et documentaire, et il se pose au début : nommer la personne qui acceptera, nommer l'acte par lequel elle le fera, et écrire ce qui se passe si elle ne le fait pas dans un certain délai. Trois lignes dans le contrat, ou à défaut trois lignes dans un courriel de lancement que personne ne contredira. Ce remède ne coûte rien au bon moment et devient impossible à appliquer une fois le travail terminé, puisqu'il faudrait alors obtenir d'une partie qu'elle s'engage sur quelque chose qu'elle a déjà reçu.

Le risque d'exploitation est lent et statistique. Personne ne décide de baisser la qualité. Le taux de rebut passe de 1,4 à 1,9 sur cinq mois, chaque valeur prise isolément semble normale, et la dérive n'est visible que dans la série. Quand elle devient évidente, elle est installée depuis longtemps et sa cause est diffuse : un réglage modifié, un fournisseur changé, un opérateur formé plus vite que d'habitude.

Son remède n'a rien de documentaire : c'est une mesure répétée dans le temps, avec un seuil décidé à l'avance et quelqu'un qui la regarde. Ni contrat, ni réunion, ni compte rendu ne détecteront une dérive de cette nature — seule une série de mesures le fera.

D'où l'erreur classique, dans les deux sens. Installer un comité de pilotage hebdomadaire sur une activité d'exploitation ne détectera aucune dérive : on y parlera d'incidents ponctuels et l'on ratera la pente. Et suivre un projet avec des indicateurs de performance mensuels ne préviendra jamais le jour où personne ne signera : aucun indicateur ne mesure l'absence d'un signataire. Le risque de projet se traite par un écrit posé au début ; le risque d'exploitation se traite par une mesure répétée jusqu'à la fin. Si vous ne deviez retenir qu'une ligne de cette page, ce serait celle-là.

Le test de deux minutes

Quand un cas refuse de se laisser classer, trois questions suffisent.

1. Y a-t-il une date après laquelle plus personne ne travaillera là-dessus ?
2. Faut-il que quelqu'un accepte le résultat, par un acte, pour que ce soit fini ?
3. Les gens qui y travaillent repartiront-ils ailleurs ensuite ?

Trois oui : c'est un projet, et il faut le piloter comme tel. Une date, un acte d'acceptation, une équipe qui se dissout — les trois dispositifs du métier ont un objet.

Trois non : c'est du quotidien, et le piloter en projet fatiguera tout le monde pour rien. Cela ne veut pas dire qu'il n'y a rien à améliorer : cela veut dire que ce qui l'améliorera est une mesure et un seuil, pas un planning et des jalons.

Un ou deux oui : c'est le cas intéressant, et c'est le seul qui apprenne quelque chose. La réponse n'est alors pas de trancher, mais d'écrire lequel des trois manque — parce que c'est précisément là que ça se passera mal, et que vous savez d'avance comment. Reprenons les trois cas, parce qu'ils se traitent différemment.

Il manque la première réponse : pas de date de fin. Vous avez un acte d'acceptation prévu et une équipe temporaire, mais rien ne dit quand cela s'arrête. C'est la configuration du chantier qui traîne : l'effort se dilue, les gens sont rappelés un par un dans leur service, et il ne reste bientôt plus qu'une personne qui s'en occupe le vendredi après-midi. Le remède est de découper : prendre la première tranche livrable, lui donner une date et un acte, et ne discuter du reste qu'ensuite. Une tranche qui finit vaut mieux qu'un ensemble qui n'en finit pas.

Il manque la deuxième réponse : personne n'accepte le résultat. Il y a une date et une équipe qui repartira, mais aucun acte d'acceptation n'est prévu, et souvent aucune personne identifiée pour le poser. C'est la configuration la plus coûteuse des trois, parce qu'elle ne fait aucun bruit avant la fin — vous livrerez dans le vide. Le remède se pose immédiatement et se pose par écrit : qui accepte, sur quel document, à quelle échéance après la demande, et ce qui se passe en l'absence de réponse. Si votre interlocuteur ne sait pas répondre, c'est déjà l'information la plus utile de votre semaine, et elle vous arrive au moment où l'on peut encore y remédier.

Il manque la troisième réponse : les gens ne repartiront pas. Il y a une fin et une acceptation, mais l'équipe restera dessus après. Vous ne construisez pas seulement un livrable : vous êtes en train de créer une activité d'exploitation, et personne ne l'a décidé explicitement. La question à poser au commanditaire est simple et rarement posée : qui fera tourner cela l'an prochain, avec quel effectif et sur quelle ligne de budget ? Le remède est de traiter dès le cadrage le passage à l'exploitation — reprise, formation, documentation, astreinte — comme un livrable à part entière, avec son destinataire. Le chapitre 7 en fait un sujet à lui seul sous le nom de transmission du savoir.

Dans les trois cas, la valeur du test ne tient pas au classement qu'il produit : elle tient à ce qu'il nomme le trou. Un trou nommé au premier mois se comble par une phrase ; le même trou découvert au neuvième coûte une négociation.

Beaucoup de travaux sont à cheval, et ce n'est pas un problème

Il faut désamorcer le classement binaire, sinon le test devient une machine à forcer des cases.

Beaucoup de travaux réels sont à cheval sur les deux colonnes, et parfaitement légitimes ainsi. Le grand arrêt annuel d'une usine a une date, une acceptation et une équipe qui se dissout — mais il revient tous les ans, avec le même mode opératoire : c'est un projet répété, qui gagne à être piloté comme un projet tout en capitalisant comme une routine. La maintenance applicative d'un logiciel est un flux continu ponctué de livraisons datées : quotidien pour l'essentiel, projet pour chaque version significative. Un déploiement site par site est une suite de projets courts sous une enveloppe unique : chaque site a sa fin et son acceptation, l'ensemble a un budget et un commanditaire.

Le test ne sert donc pas à trancher mais à nommer où le travail penche, et sur quelle ligne précisément. C'est une information beaucoup plus utile qu'une étiquette : elle dit quels dispositifs installer et lesquels laisser de côté. Un arrêt annuel a besoin d'un acte d'acceptation et n'a pas besoin d'une étude de cadrage refaite chaque année ; une maintenance applicative a besoin d'une mesure de dérive et d'un acte d'acceptation par version.

Et quand une activité penche des deux côtés, dites-le à voix haute plutôt que de choisir en silence. La phrase qui règle la plupart de ces situations en réunion est courte : nous traitons cela en projet jusqu'à la mise en service, puis en exploitation, et voici la date et l'acte qui font passer de l'un à l'autre.

À quoi ça ressemble dans AB

Trois réglages suffisent à faire vivre cette page, et ils tiennent en une demi-heure.

Séparez les deux natures de travail. Un projet et une activité d'exploitation ne se rangent pas au même endroit et ne se lisent pas de la même façon. Mélangés dans la même liste, l'exploitation noie le projet, parce qu'elle produit dix fois plus de lignes et qu'elles sont toutes urgentes. C'est la version outillée du constat de la ligne équipe : sans séparation explicite, le quotidien gagne.

Faites porter au projet un jalon de fin qui a deux champs obligatoires, une date et un document. Tant que le second est vide, le jalon n'est pas atteint, même si tout le monde considère que c'est terminé. C'est la traduction, dans un outil, de la première ligne du tableau — et c'est ce qui empêche un projet de se terminer sans que personne l'ait constaté.

Inscrivez le résultat du test de deux minutes dans la fiche du projet, en toutes lettres, à trois valeurs : projet, quotidien, ou mixte avec la mention de ce qui manque. Cette dernière ligne est celle qui a de la valeur. Pas d'acte d'acceptation identifié écrit en semaine deux devient un point ouvert avec un responsable et une date, ce qui est très exactement le contraire d'une inquiétude diffuse dont personne ne s'occupe.

Les termes de cette page

Projet

Un effort qui a un début, une fin et un résultat qui n'existait pas avant, et dont quelqu'un répond. Développer

Exploitation, le quotidien

Le travail répétitif qui fait tourner l'entreprise, sans fin prévue, et qu'on mesure à sa stabilité. Développer

Livrable

Ce qui est remis et peut être constaté : un objet, un document, un état vérifiable — pas une activité. Développer

Jalon

Une date à laquelle quelque chose est vérifiablement terminé, pas une date à laquelle on a travaillé. Développer

Réception

L'acte par lequel le maître de l'ouvrage déclare accepter l'ouvrage, avec ou sans réserves (art. 1792-6). Développer

Taux de charge

La part du temps d'une personne déjà engagée ailleurs : l'indicateur qui explique pourquoi le projet n'avance pas. Développer

Forfait annuel en jours

Un décompte en jours et non en heures, plafonné à 218 : d'où la planification en jours-personne. Développer

Double casquette

Mener un projet tout en tenant son poste : deux définitions du succès pour une seule personne. Développer

CSE

Le comité social et économique : obligatoire à partir de onze salariés, avec des attributions élargies à cinquante. Développer

Consultation du CSE

Dans les entreprises de cinquante salariés et plus : un avis, jamais une autorisation, dans un délai qui court de la communication des informations. Développer

Commanditaire

Celui qui répond du projet au-dessus de vous et tranche ce que vous ne pouvez pas trancher. Développer

Transmission du savoir

Le passage du projet à ceux qui l'exploiteront : un livrable à part entière, avec un destinataire nommé. Développer

Pour aller plus loin

Vous êtes arrivé au bout du chapitre 1. Les chapitres suivants — cycle de vie, planification, équipe, outils, suivi, clôture — sont en cours de réécriture dans cette édition ; le sommaire les recense au fur et à mesure de leur mise en ligne.