Je me souviens d’un projet qui a réellement fonctionné, il y a très longtemps, dans une galaxie très lointaine. J’avais environ 25 ans à l’époque, beaucoup d’énergie et sans doute un peu plus d’illusions qu’aujourd’hui. Je pensais qu’un projet bien mené était la norme, qu’avec des gens sérieux, du travail et un peu de méthode, les choses finissaient par se mettre en place.
Avec le recul, je pense que c’était probablement le projet le plus réussi auquel j’ai participé. Je parle d’un véritable succès, pas d’un projet déclaré “vert” dans un comité de pilotage alors que tout le monde sait que ça ne va pas bien se passer. Je parle d’un projet qui tenait debout, qui après deux ou trois mois de tests par le client, n’a remonté que trois bugs.
Trois bugs seulement pour une refonte complète qui a duré presque deux ans avec une équipe de quinze personnes. Rien que d’y penser, ça me semble un peu irréel. Dans beaucoup de cas, ce n’est plus un projet réussi, c’est un mythe.
Mais il ne faut pas dire que tout était facile. Il y a eu des difficultés, des tensions, des excès et des angles morts. Mais il y avait aussi une vraie exigence collective.
Le contexte
Le contexte était favorable. On ne partait pas de zéro, on refondait un logiciel que l’entreprise connaissait très bien. Et l’équipe qui travaillait déjà sur la version en production participait aussi à la refonte. Cela semblait presque logique, mais je sais que ce n’est pas toujours le cas, voire que c’est rarement le cas.
La base du succès
Ce qui me frappe encore aujourd’hui, c’est la solidité du travail préparatoire. Tout avait été repris, les spécifications de haut niveau, les spécifications détaillées, les règles de gestion, les descriptions des zones, les maquettes d’écran… Tout était relu, d’abord en interne, puis avec le client.
Itérer sérieusement
Ensuite, on avançait pas à pas. On concevait un premier écran, puis on adaptait, puis un autre… On itérait sérieusement, on acceptait que la conception se construise progressivement.
Le développement suivait la même logique. On développait, on faisait des tests unitaires, on relisait, on corrigeait… La qualité n’est pas tombée du ciel, elle a été fabriquée patiemment et sérieusement.
Ce projet avait quelque chose de vivant dans son fonctionnement. Les rôles n’étaient pas figés, l’équipe bougeait selon les besoins. On pouvait passer de la conception technique au développement, du développement aux tests…
Mais il y avait un prix
Ce serait facile de s’arrêter là et de transformer ce souvenir en belle histoire, mais ce serait faux. Il y avait des tensions, des désaccords, des critiques… Des gens qui savaient valoriser leur contribution, mais beaucoup moins bien reconnaître celle des autres.
Et puis il y avait les horaires, du 8h à 20h, parfois 22h. Je n’avais pas d’enfants, j’étais jeune, j’arrivais tôt, je repartais tard… Mais à 22h, nous étions nombreux.
Ce n’était pas tous les jours un enfer. Il y avait des pauses, des moments où l’on pouvait se ressourcer. On faisait parfois du sport à midi, et il y avait une certaine ambiance. Ce n’était pas un endroit où l’on se sentait prisonnier, mais ce n’était pas non plus un environnement sain. Il faut être honnête, le projet n’a pas seulement réussi grâce à la méthode. Il a aussi tenu grâce à une quantité énorme de travail.
Cela ne retire rien à la qualité du résultat, mais cela change la façon dont on l’interprète.
Le moment où le projet rappelle qu’il est aussi une affaire de gestion
Je me souviens d’un moment particulièrement brutal : Une réunion, après quelques mois…
Le message était clair : vous prenez trop de temps, vous avez du retard, mais heureusement, il y avait une marge de sécurité. Cette marge est désormais épuisée, il n’y a plus de filet de sécurité.
En d’autres termes, vous avez utilisé la réserve prévue pour absorber les imprévus, donc à partir de maintenant, il n’y a plus de réserve pour absorber les imprévus. Conceptuellement, c’est audacieux, mais cela me semble aussi un peu fou. C’est comme retirer les freins parce qu’on a déjà trop freiné, ou supprimer le parachute de secours parce qu’on a beaucoup parlé de sécurité.
Et c’est là que la question devient intéressante : La faute à qui ?
Aux développeurs ?
À l’équipe ?
À un manque d’engagement ?
À une lenteur supposée ?
Ou simplement à une estimation initiale imparfaite ? À un pilotage qui n’a pas voulu réajuster à temps ? Au refus de dire clairement : “Nous nous sommes trompés” ?
Avec le recul, je crois que c’est une leçon importante : un projet peut être très bien exécuté, mais mal planifié.
Et quand cela arrive, ce sont souvent les équipes qui paient la différence. Avec leur temps, leur énergie, parfois leur santé. Ensuite, on appelle cela de l’engagement ou de la mobilisation. Les mots sont élégants, mais le mécanisme l’est beaucoup moins.
La vraie leçon
La vraie leçon de ce projet n’est pas de dire que les gens étaient courageux avant et qu’aujourd’hui ils se plaignent. Ce serait une lecture paresseuse et un peu bête.
La vraie leçon, c’est plutôt celle-ci :
oui, avec de la méthode et du temps, on peut faire des choses remarquables ;
oui, itérer fonctionne ;
oui, relire fonctionne ;
oui, faire travailler ensemble des profils différents fonctionne ;
oui, la qualité demande de la rigueur, de la visibilité et de l’engagement.
Mais non, les heures supplémentaires non payées ne sont pas un ingrédient normal de la réussite.
Le plus souvent, elles sont le symptôme d’une organisation qui n’a pas voulu regarder ses propres limites en face. Autrement dit, la méthode produit la qualité, mais l’épuisement compense les erreurs de pilotage. Et confondre les deux, c’est une faute d’analyse, pas une preuve d’expérience.
Et maintenant, qu’est-ce qu’on en fait ?
C’est la seule question qui m’intéresse.
Il ne s’agit pas de rêver à un retour intégral aux projets d’il y a vingt-cinq ans, avec les classeurs, les fiches cartonnées et les réunions UML.
En revanche, il y a des choses à récupérer :
- La clarté des attentes
- La précision fonctionnelle
- La relecture
- Les validations réelles
- La progression technique par étapes
- Le droit de corriger
- La visibilité partagée
- La polyvalence encadrée
- La proximité de travail
Et il y a aussi des choses qu’on peut laisser tranquillement au musée :
- Les horaires à rallonge
- La confusion entre engagement et sacrifice
- L’idée qu’une erreur d’estimation peut se rembourser en dette humaine
- La tentation de récompenser davantage ceux qui parlent fort que ceux qui tiennent réellement le projet
Le souvenir que je garde de cette période est donc double. Oui, c’était une vraie réussite. Oui, j’ai aimé ce projet, vraiment. Oui, j’y ai appris énormément.
Mais avec l’âge, je comprends mieux qu’un projet exemplaire n’est pas seulement un projet qui livre bien.
C’est un projet qui livre bien sans abîmer ceux qui le portent. C’est un projet qui reconnaît que chacun apporte quelque chose, avec ses forces, ses limites, ses contraintes. Un projet qui sait demander des efforts sans considérer qu’on peut tirer indéfiniment sur la corde. Un projet qui ne confond pas esprit d’équipe et disponibilité sans fond.
C’est un projet qui livre bien sans abîmer ceux qui le portent !
Et ça, au fond, on devrait peut-être le traiter avec autant de sérieux qu’un schéma de base de données.