La recette : le moment où l'organisation rencontre enfin le réel
À travers cet article, je propose une autre lecture de la recette : celle d'un moment où le projet cesse d'être un discours pour se confronter au réel. Une réflexion destinée à tous ceux qui participent, de près ou de loin, aux transformations des systèmes d'information.
6/22/20264 min read
Pendant des mois, un projet SI peut vivre presque exclusivement dans le discours.
Les besoins sont expliqués.
Les ateliers produisent des comptes-rendus.
Les comités valident des orientations.
Les démonstrations rassurent.
Les plannings avancent.
Et parfois, tout semble fonctionner.
Puis vient la recette.
À partir de là, quelque chose change : le projet cesse peu à peu d'être une histoire que l'on raconte pour devenir une réalité à laquelle il faut se confronter.
La recette ne valide pas uniquement une solution informatique
On présente souvent la recette comme une simple étape de validation fonctionnelle.
Une checklist avant la mise en production.
Pourtant, elle met à l'épreuve bien davantage qu'une solution informatique (nouvelle application, correction ou évolution du Système d’Information).
Elle questionne :
la compréhension du besoin
la solidité des arbitrages pris plusieurs mois auparavant
les compromis accumulés au fil du projet
les zones volontairement laissées dans le flou
et parfois même... la capacité d'une organisation à accepter le réel
Tant que la solution n'est pas utilisée dans des situations concrètes, chacun peut continuer à avoir sa propre lecture du projet.
Le métier imagine que le besoin est bien compris.
La MOA pense l'avoir sécurisé.
La MOE est convaincue d'avoir développé conformément aux spécifications.
Les managers voient un planning qui tient.
Puis la recette arrive.
L’application répond... Ou elle ne répond pas.
À partir de cet instant, il ne s'agit plus d'interpréter le projet.
Il s'agit de constater.
Le retour du réel
C'est probablement ce qui rend la recette si particulière.
Pendant plusieurs mois, un projet peut avancer grâce au discours.
Certaines imprécisions passent inaperçues.
Les formulations restent suffisamment larges pour que chacun puisse encore s'y retrouver.
La recette réduit brutalement cet espace.
Les questions deviennent beaucoup plus directes :
Est-ce que cela fonctionne ?
Est-ce exploitable ?
Est-ce cohérent avec les pratiques métier ?
Est-ce acceptable pour les utilisateurs ?
Le système tient-il réellement lorsqu'on le confronte au quotidien ?
Les anomalies découvertes ne sont d'ailleurs pas toujours des erreurs de développement.
Elles révèlent souvent autre chose :
un besoin insuffisamment stabilisé
des règles métier contradictoires
des arbitrages jamais réellement assumés
des usages que personne n'avait anticipés
La recette révèle parfois moins les faiblesses du logiciel... que celles du projet.
Le paradoxe de la non-régression
Les tests de non-régression font partie des activités les plus discrètes d'un projet.
Et pourtant, ils sont essentiels.
Lorsqu'ils sont bien réalisés... Il ne se passe rien.
Personne ne félicite une équipe parce qu'une anomalie n'est jamais apparue.
Pourtant, dans un Système d'Information, chaque évolution peut fragiliser silencieusement un équilibre construit depuis parfois plusieurs années.
Modifier un écran.
Ajouter une règle.
Corriger un calcul.
Tout cela peut produire des effets bien au-delà du périmètre concerné.
La non-régression ne consiste donc pas uniquement à tester une évolution.
Elle consiste à vérifier que le système continue de tenir malgré le changement.
Au fond, elle pose une question beaucoup plus large : « Une organisation est-elle capable d'évoluer sans se désorganiser elle-même ? »
Peut-on réellement recetter le changement ?
Un autre paradoxe apparaît.
Nous savons tester une fonctionnalité.
Nous savons vérifier un calcul.
Nous savons contrôler un traitement.
Mais savons-nous réellement tester le changement ?
Une recette réussie techniquement ne garantit jamais :
l'adhésion des utilisateurs
l'évolution des pratiques
l'appropriation des nouveaux processus
l'acceptation du changement
Combien de projets ont parfaitement réussi leur recette...
...avant d'échouer quelques mois plus tard dans les usages quotidiens ?
Comme si la véritable recette ne commençait finalement qu'après la mise en production.
Sisyphe dans la salle de recette
En écrivant cet article, une image m'est revenue : Celle de Sisyphe.
Dans Le Mythe de Sisyphe, Camus raconte l'histoire de cet homme condamné à pousser éternellement son rocher jusqu'au sommet de la montagne avant de le voir redescendre.
À première vue, cette image paraît pessimiste.
Pourtant, Camus ne s'intéresse pas tant au rocher qu'à l'homme.
Il ne cherche pas à savoir comment Sisyphe pourrait enfin terminer son travail.
Il s'interroge sur ce qui le pousse à recommencer.
Je me demande parfois si nos systèmes d'information ne ressemblent pas un peu à cela.
Une recette est validée.
Puis une évolution apparaît.
Une anomalie est corrigée.
Puis une nouvelle réglementation arrive.
Un projet est clôturé.
Puis un autre démarre.
La recette porte peut-être, elle aussi, une forme d'absurde au sens de Camus.
Chaque validation semble annoncer une fin qui n'arrive jamais vraiment.
Une anomalie corrigée laisse place à une nouvelle évolution.
Un projet terminé ouvre déjà le suivant.
Comme Sisyphe retrouvant son rocher au pied de la montagne, les équipes SI recommencent sans cesse.
Mais peut-être que la question n'est pas de savoir quand ce cycle s'arrêtera.
Peut-être est-elle de savoir ce qui nous pousse à continuer malgré son caractère interminable.
Après tout, un Système d'Information qui n'évolue plus est souvent un système qui commence à commence à perdre sa capacité à accompagner l'organisation
Alors, la recette marque-t-elle réellement la fin d'un projet ? On nous rappelle-t-elle simplement qu'un système d'information n'est jamais vraiment terminé ?