Il y a fort fort longtemps…
Le métier, ayant besoin d’un nouveau site internet, consultait le service informatique.
Une équipe de concepteurs prenait en charge cette demande, déclenchant une période d’étude et d’analyse.
Cette équipe, extrêmement compétente, composée de tous les meilleurs experts dans leur domaine, récoltait le besoin, le raffinait, le questionnait, le creusait, interviewait et auditait les utilisateurs …
Durant ce travail minutieux et théorique, elle prenait le temps nécessaire pour imaginer tous les scénarios de toutes les fonctionnalités, anticiper et résoudre tous les potentiels problèmes…
Ainsi, l’équipe de conception élaborerait la solution idéale.
Toute cette précieuse étude était ensuite couchée sur papier, pour ne rien oublier, être le plus précis et exhaustif possible. Des documents denses et volumineux étaient livrés avec, au choix, des maquettes des écrans, des prototypes, des schémas d’architecture logicielle, des diagrammes de séquences, ou UML, des spécifications Swagger…
Le tout était validé et contractualisé, faisant foi.
Ainsi rassurés, il ne restait plus que la partie « facile » : donner corps, réaliser et concrétiser ce magnifique plan.
Documentation sous le bras, il était temps de consulter les équipes de réalisation. Les équipes internes, externes, l’important était de vite choisir le meilleur rapport qualité-prix.
Ces équipes consultées étudiaient tous les documents fournis avec minutie et professionnalisme, pour sortir un prix compétitif, mais tout de même rentable, en tout cas sur le long terme.
En fonction de ce prix, un rétro-planning était déduit, avec une date de début de travaux et une date de livraison finale.
Suivait une période de garantie au terme de laquelle la solution idéale était concrétisée.
Le plan était parfait.
A la date précise, le site web livré était lancé, magnifique, parfaitement conforme à toutes les documentations imaginées, indiscernable des maquettes validées. Tout ce qui avait été envisagé avait été réalisé, tous les problèmes rencontrés avaient été anticipés et solutionnés grâce aux documents d’analyse. Les utilisateurs n’en croyaient pas leurs yeux : le moindre de leurs désirs avait été exaucé.
Et… ils vécurent heureux et eurent beaucoup d’enfants…
EHHHHHH… vous 🫵 !!!! Vous croyez encore au Père Noël 🎅 ? Il est temps de grandir un peu, et ça va être brutal, un peu comme Edward Norton qui découvre sa double identité… (désolé pour le double spoil).
Alors, soyons francs : ce modèle idyllique n’a jamais fonctionné, et cela a été prouvé pendant plusieurs décennies. Et malheureusement, il hante encore nos couloirs… non pire… c’est sa version dégénérée qui hante nos couloirs !!! Qui sait à notre époque encore rédiger un vrai cahier des charges, un vrai rapport d’adéquation de l’époque ? Les derniers reliques, que nous pourrions retrouver, doivent être celles du “passage à l’€uro” et “la résolution du bug de l’an 2000”… En plus, maintenant nous avons JIRA ….😖hhmm… ça fait froid dans le dos !!!!
Rétablissons la vérité
⚠️ Mais avant un petit disclaimer : nous partons du principe que tous les acteurs sont extrêmement compétents, bienveillants, impliqués et motivés. Ce n’est pas un sujet “d’Homme”, c’est un sujet de mindset.
Voici quelques évidences :
Problème — La « période d’étude et d’analyse » c’est long et … vain
Il s’agit d’une phase fréquemment très étendue et, par conséquent, coûteuse, pendant laquelle le monde ne s’arrête pas de tourner ; les besoins continuent d’évoluer. En outre, sa durée constitue une part intégrale du projet. En effet, bien que le TTM (Time To Market) prenne généralement en compte uniquement la phase de « réalisation », l’étape d’étude et d’analyse est souvent, et volontairement, oubliée. Cette omission peut rassurer toutes les parties prenantes, mais, en réalité, l’utilisateur final s’en trouve impacté.
Problème — Anticiper et résoudre tous les potentiels problèmes
De nature optimiste, je pense qu’avec du temps… beaucoup de temps… mais alors vraiment beaucoup beaucoup… de temps… c’est pas impossible de se rapprocher de cet idéal… enfin de loin… en même temps, il y a un adage qui dit que c’est au pied du mur que l’on voit le mieux le mur… et un autre, à l’impossible nul n’est tenu… Bref, des gens sérieux pensent sérieusement que l’on peut prévoir sérieusement l’imprévisible, ... sérieux ???
Problème — Valider des prototypes et maquettes
“Ne pas limiter le champ des possibles”, “s’affranchir des contraintes”, “adopter une approche destructive”, “proposer des idées novatrices”, “tester des prototypes auprès des utilisateurs”, “réaliser des tests A/B”…
Eh oui, nous sommes totalement d’accord : c’est une profession, une étape cruciale et déterminante dans la réussite d’un projet. C’est évidemment pas le sujet.
Cependant, une fois les maquettes finales validées, n’est-ce pas un peu tard pour se poser les questions fondamentales : Est-ce techniquement faisable ? Et surtout, question essentielle, avons-nous les moyens financiers pour cela ? Malheureusement, nous réalisons rapidement que dessiner un château ne signifie pas forcément avoir les moyens de se l’offrir, ou de savoir le construire. Pourtant, pour d’autres aspects, dans le monde numérique, ignorer cette évidence ne semble poser aucun problème… Alors, attention au rétropédalage quand la réalité viendra heurter la fiction… bip… bip… bip… bon courage à toute l’équipe !!!
Problème — Toutes les estimations sont, par définition, FAUSSES !!!
Vous êtes surpris ? Vous souhaitez découvrir l’envers du décor ? Comment un développeur réagit-il à la question : “Combien pour réaliser cette solution si bien décrite ?”
D’abord, il soufflera, puis, face à votre insistance, commencera à lire votre document… ouf, c’est long … encore plus long que cet article medium… En quelques minutes, son attention déclinera. Il prendra alors son index, l’humectera et le lèvera vers le ciel, avec la plus grande concentration… afin d’apprécier les courants et les flux d’air… puis, arborant son air le plus sérieux, il vous annoncera : “Pour tout ça …. mmm… c’est 42”…
Ce running gag perdure à travers les générations de développeurs depuis des décennies. Nous le savons tous et le clamons depuis tant d’années. Mais cette question nous revient sans cesse.
Bien sûr, vous désirez un chiffre plus “sérieux”... Alors, généralement, Nous allons nous remettre sur notre chaise, nous prendrons votre document, ou mieux, si vous l'avez découpé en US (User Stories) dans un “backlog” ou un Excel, nous le chiffrerons avec le plus grand sérieux, ligne par ligne, US par US. Malin, et surtout “ayant appris à faire la grimace” à nos dépens, nous appliquerons une large marge (du *2 ou *3). Notre supérieur, plus expérimenté et donc généralement “le roi des grimaces”, ajoutera une “surmarge”. Il en résulte souvent un facteur *7 entre le chiffrage de base et celui "vendu".
Attention, ce n'est pas du vol, c'est du all inclusive : les salaires des développeurs, des testeurs, des chefs de projet, les locaux, le matériel, nos processus, nos livrables, nos prototypes... et surtout, le poste le plus important, nos erreurs. Enfin : les nôtres, celles des concepteurs, des utilisateurs, du client, du designer, de l’architecte, du coach, les vôtres…
Bien sûr, il est impossible pour notre “commercial”, ou “notre responsable de service” d’annoncer ce chiffre, surtout si la concurrence, ou notre métier, est plus agressive, auquel cas le projet nous échapperait… Ainsi, c’est le moment des promotions, et nous nous rattraperons plus tard, car comme le dit l’adage dans notre métier, l’important est de mettre le pied dans la porte. Car nous savons, hein !!! 😏 Une date de fin finalement 😏 c’est fait pour être repoussée, non ? 😏 Et une fois que le projet est lancé, impossible de refuser notre avenant, non ? 😏 Sinon il leur reste quoi ? 😏 …Rien un truc, qui ne fonctionne même pas, au mieux, il est la concrétisation des premières pages du document d’analyse, et ce n’est pas les plus intéressantes… ce truc leur servira à peine à caler une porte… ça fait “cher” le bloque-porte Ahhh…. des rires encore plus gras… Ahhh…
Mais alors, si le chiffrage est impossible, que faire ? La réponse est étonnamment simple : une date de fin ne se calcule pas, ne s’estime pas, elle se DÉCRÈTE. Il faut s’octroyer un délai, et le reste doit en découler… cela implique, si vous avez suivi, une incompatibilité totale avec la rédaction d’un document ou d’un plan figé.
And yet tomorrow, it was written in 2001 !!!
Ces constats, et d’autres, ont été réalisés il y a de nombreuses années. Une solution a été avancée pour y répondre en février 2001. En théorie, aujourd’hui, toutes les entreprises ont adopté ce mode de fonctionnement. Ces principes ont été élaborés de manière destructive, reconnaissant que les modèles d’inspiration industrielle ou intuitifs n’étaient pas adaptés au contexte très spécifique de l’ingénierie logicielle.
Il est désormais considéré comme acquis et est appliqué, littéralement, à toutes les sauces :
“Nous avons fait un peu à notre sauce, car toute leurs théories ne peuvent pas fonctionner chez nous, nous, nous sommes spéciaux…”
Ce vent de scepticisme souffle. Nombreux sont ceux qui ont entrepris leur transformation, et presque autant se disent : ‘Mmmmh, ça ne fonctionne pas si bien que ça…’. Ils abandonnent, ou succombent à l’attrait d’un nouveau framework, une nouvelle couche à la mode, poussé par ce si cher cabinet conseil. Ou non !!!!! C’est la faute des coachs : “Regarde là-bas, celui-là a l’air mieux, il est aérien et docile. Je suis sûr qu’il nous dira ce que nous voulons entendre !”
Le scepticisme, dans ce contexte, traduit une incompréhension totale des principes établis. Ces derniers ne peuvent pas, par définition, « ne pas fonctionner ». Leur postulat, leur promesse, n’est que : livrer à une date définie, précise et immuable, le maximum de valeur possible. Ainsi, le coût et le délai sont maîtrisés, tandis que le contenu livré est fonctionnel mais variable.
Il est donc impossible que la promesse ne soit pas tenue : « Vous obtiendrez le meilleur possible pour votre investissement. »
Instant pub : “Avec la Co-construction empirique et itérative impossible de louper votre projet 😜”.
Et vous ?
Êtes-vous réellement transformés, éveillés ? Vos maquettes sont-elles systématiquement validées avant que les développements commencent ? Vous arrive-t-il de livrer vos produits avec un peu de retard ? Est-ce que vos business analystes rédigent vos User Stories en amont ? Vos développeurs, sont-ils régulièrement sollicités pour chiffrer des projets ? Ne livrez-vous pas vos développements systématiquement toutes les deux semaines ? Utilisez-vous des KPI pour projeter la date de fin de votre projet ? …
Si vous répondez “OUI” à l’une de ces questions, alors… vous savez. Vous savez que vous vivez avec plusieurs décennies de retard et que votre transformation est un échec. Et là, dans votre tête, résonne “Where Is My Mind?” des Pixies… de manière obsédante… Welcome to schizophrenia land !!!
Il y aura dans fort fort pas trop longtemps !!! (Enfin nous l’espérons pour vous)
Le métier, ayant besoin d’un nouveau site internet, consultera le service informatique.
Rapidement, les enjeux commerciaux permettront d’allouer un premier budget réaliste favorisant un retour sur investissement rapide, entendable et réaliste. Une équipe pluridisciplinaire et autonome sera constituée. Une date de fin de projet sera décrétée et considérée, par tous et pour du vrai, comme absolument intangible. Les développements et les livraisons commenceront le jour même.
Dès lors, tous les acteurs et le client s’engageront dans des objectifs itératifs et livreront un produit toutes les deux semaines, puis continuellement : LA COLLABORATION AVEC LES CLIENTS PLUS QUE LA NEGOCIATION CONTRACTUELLE… Chaque itération bénéficiera d’un retour d’expérience, des retours terrain, à l’écoute des utilisateurs, et aura un impact direct sur la livraison suivante : LES INDIVIDUS ET LES INTERACTIONS PLUS QUE LES PROCESSUS ET LES OUTILS… car oui, nous aurons enfin accepté nos faiblesses et nos limites, prévoir l’imprévisible est impossible, l’anticipation s’avère toujours plus coûteuse que l’exécution, les plus belles maquettes et les documents d’analyse les plus détaillés n’ont en eux-mêmes aucune valeur et ne garantissent en rien les meilleures applications : DES LOGICIELS OPERATIONNELS PLUS QU’UNE DOCUMENTATION EXHAUSTIVE… Notre client, nos utilisateurs et le monde n’attendront toujours pas, figés ; pour comprendre un problème, mieux vaut s’y confronter directement ; l’erreur fera partie du processus, et ce que nous saurons, c’est que nous ne savons pas : L’ADAPTATION AU CHANGEMENT PLUS QUE LE SUIVI D’UN PLAN…
Ahh !!! vous réfléchissez encore à ce site web parfait ? euh nous c’est bon, nous l’avons terminé.
Un exemple ?
Un peu de teasing : comment pouvons-nous mettre en pratique ces principes ? Le prochain article sera un retour d’expérience sur un projet web publique au sein d’AXA.fr, du concret en perspective.
Retroussons nos manches and “Raise the bar” 😉 !!!!!
Remerciements : A la “5 Guys — CoreTeam”, où nous partageons nos peines, nos souffrances, nos doutes et nos joies, pour nous permettre de garder le cap : Mélanie, Emmanuel, Jean-Christophe, Mathieu, et Silvere. A Cédric Pourbaix, que j’ai eu la chance d’avoir comme coach agile il y a plus de 10 ans. Je prends conscience chaque jour de la qualité et la pertinence de son enseignement, que je recycle en boucle depuis cette date. A mes patrons de l’époque, Thibaut & Thibaut , d’avoir investi et anticipé ce virage, et qui nous ont offert “la meilleure formation de ma vie”. A notre ancien chef, Laurent, de nous avoir poussé et donné le courage de relever ce défi.
