Business et tech : deux mondes opposés ?
En France, on note un taux très élevé de projets technologiques qui sont de véritables catastrophes financières. Tous les jours, des chantiers tech subissent des difficultés, des échecs.
La culture française a toujours mis une barrière entre le business et l’exécution tech, ne laissant que très peu d’échanges entre ces deux mondes. Cette frontière métier crée, structurellement, un manque de communication entre les équipes dont le langage et les objectifs diffèrent. Cet ancrage culturel conduit inéluctablement à la réalisation de solutions tech qui ne répondent pas aux besoins des utilisateurs finaux. Le résultat : une perte de temps, d’argent et une grande frustration générée auprès des donneurs d’ordre et des opérateurs tech. Dès lors, quelle stratégie adopter pour faciliter les échanges entre ces deux univers et que les objectifs de l’un fassent écho chez l’autre ?
Aligner tech et business : la condition sine qua non de la réussite d’un projet
Selon les chiffres du Standish Group Chaos Report, 83,9% des projets informatiques échouent et 31,1% d’entre eux sont stoppés en cours de route et ne sont jamais déployés. Des chiffres révélateurs de nombreux problèmes structurels dans la conception et le développement de produits tech. Selon le PMI*, une mauvaise communication constitue l’une des causes principales d’échec d’un projet.
Au commencement d’un projet digital, les équipes business émettent un besoin qui est ensuite traduit sous la forme d’un cahier des charges, finalement transmis aux équipes tech. Ce processus est fait en tout point pour que l’ensemble des étapes se réalisent en séquentiel. Les équipes business dans un premier temps. Les équipes techniques dans un deuxième temps. Chacun son travail, pas besoin d’échanger ! Dans un monde parfait, c’est un processus qui pourrait fonctionner mais la réalité est tout autre. Et à ce sujet, les chiffres sont formels : 52,7% des projets dépassent de 189% leurs prévisions budgétaires. Les projets informatiques qui respectent le budget et les délais s’élèvent à 16,2%, ce qui est extrêmement faible au vue des enjeux.
Concrètement, les équipes business passent des semaines, voire des mois, à réaliser un cahier des charges qui sera totalement déconnecté de la réalité d’un projet informatique. Pourquoi ? Parce que la réalisation de ce document oblige le concepteur à penser à tout un tas de fonctionnalités et d’écrans qui le détournent des véritables besoins des utilisateurs. L’impact est assez simple : spécifications non complètes, non claires ou ambiguës pour les équipes tech qui vont construire un mauvais produit qui ne sera utilisé par personne.
Les équipes tech ont besoin de comprendre l’environnement dans lequel le produit évolue. C’est la raison pour laquelle il est nécessaire de changer de méthodologie. Exit le cahier des charges qui se veut un élément perturbant et peu clair. D’un travail en séquentiel, il faut passer à une vision simultanée dans laquelle les équipes tech et business se parlent en direct et de façon quasi instantanée pour que ne former plus qu’une seule et même équipe dédiée au produit. Ce changement radical est incontournable pour améliorer la rentabilité des projets tech français.
Favoriser la prise de risque : la stratégie “test and learn”.
Les hypothèses sont à la base d’un projet. Si elles ne sont pas vérifiées, c’est la structure entière qui est bancale. Il ne reste alors plus qu’à tout recommencer. Une perte de temps considérable qui peut être évitée. Sur 100 projets qui sont initiés, 94% sont des redémarrages. Une seule façon possible de valider ses hypothèses : les confronter à la réalité.
En France, l’état d’esprit qui prédomine est qu’un projet doit être réalisé à la perfection pour mériter de voir le jour. Il n’en reste pas moins que cette vision des projets informatiques est tout simplement irréaliste, les taux d’échec le prouvent ! En effet, un produit digital est structurellement en évolution permanente. Cette transformation s’opère pour se rapprocher au plus près des besoins mouvants des utilisateurs finaux. Le lancement est la première étape de mise en relation avec les utilisateurs. Il permet de se confronter à son marché et de faire évoluer le produit au contact des retours utilisateurs.
A ce jour, certains projets ne sont pas lancés après des mois ou années de travail car ils ne répondent pas aux exigences du cahier des charges ! On se trompe de combat. Le produit digital à sa sortie n’a qu’un seul juge : l’utilisateur. Quelle hérésie de penser que les concepteurs du produits connaissent mieux les besoins que leurs propres clients. Ne pas lancer un projet qui est perfectible conduit à une perte considérable de temps et à des produits résolument obsolètes. Pour transmuer ces manières de penser, les décideurs doivent impérativement comprendre que lancer un produit imparfait permet d’une part de commencer à répondre au besoin et d’autre part de mettre en route son évolution.
Il est important de préciser qu’adopter cette stratégie sera moins difficile si l’on commence par des projets périphériques. En effet, s’atteler de prime abord au cœur de métier risquerait de déstabiliser l’organisation interne. Sur des projets centraux, les salariés sont soumis à davantage de stress et de frictions, alors que commencer par des actions périphériques fait gagner du temps et crée de la valeur. Selon le PMI, les gros projets ont 10 fois plus de chances d’accuser un retard, de dépasser le budget et de passer à côté de fonctionnalités critiques en comparaison avec les plus petits projets.
En France, il est coutumier de se comparer aux Américains, parfois à tort, parfois à raison. Mais d’il y a bien une chose que nous pouvons importer des États-Unis, c’est leur capacité à se confronter rapidement à leur marché. Peu frileux lorsqu’il s’agit de sortir un produit imparfait, ils concentrent ensuite leurs efforts à l’améliorer au contact des utilisateurs. Une démarche inspirante, qui demande à prendre quelques risques, mesurés, mais permet de s’éloigner d’un perfectionnisme souvent trop sclérosant et à l’origine de l’échec de nombreux projets tech.