Combien de vos clients sont arrivés chez vous la gueule enfarinée en annonçant “Nous savons exactement quel logiciel il nous faut. En voici les prérequis, et les spécifications détaillées. Contentez-vous de le développer, le tester, et nous le livrer dans les temps”. C’est, semble-t-il, l’expérience vécue à plusieurs reprises par Abhijit Nadgouda, qui nous en fait part dans un coup de gueule incisif.

Il est quelque part normal que les clients aient l’impression de savoir ce qu’ils veulent, et je trouve ce reflex plutôt sain. Cela signifie tout simplement qu’ils ont un problème, et qu’ils ont fait le tour de la question avant de proposer une solution qui leur semble adéquate. Ils arrivent généralement avec deux tonnes de documents, souvent faits sous Excel, pleins d’études de cas, solutions et ROI à l’appui. Tout ce qu’ils vous demande après tout, c’est de développer leur outil, de le tester, puis de le livrer. Ils se sont chargés de la conception de A à Z, ce qui permet de gagner à la fois du temps, et de l’argent.

C’est peut-être là que le bat blesse. Bien que cette démarche semble pleine de sens et de bon sens, elle méconnaît quelques règles fondamentales du développement logiciel, et renvoie le côté technique au rang de simple variable d’ajustement ©, en rejetant le fait que la solution choisie puisse avoir un impact fondamental dans la résolution des problèmes à traiter.

De nombreux clients sont en décalage total avec l’évolution du monde du logiciel, quelles qu’en soient les raisons : manque d’intérêt ou de sang neuf au SI, attachement à une solution fermée sans possibilité de connexion externe… Si l’on s’en tient au seul domaine de la publication en ligne, ces derniers subissent un électrochoc culturel quand ils se heurtent aux solutions de publication modernes, au web participatif… Certaines clients revoient leur copie, en intégrant les solutions du moment à leurs besoins métiers, perdant ainsi beaucoup de temps, et d’argent. D’autres, au contraire, restent sur leurs position et leur culture, passant à côté d’un important retour sur investissement.

Abhijit Nadgouda définit le développement logiciel comme l’action de trouver une solution à un problème en y intégrant tous les enjeux de manière adéquate. Ce qui commence évidemment par identifier les problèmes et les enjeux. Bien souvent, en se focalisant sur la réponse à une seule question, les spécifications apportées par le client passent à coté de ces enjeux, et l’application en résultant est souvent un échec total.

Là où mon avis diverge de celui d’Abhijit Nadgouda, c’est sur les raisons qui mènent à un tel échec. Abhijit Nadgouda met en avant le manque de confiance du client envers son prestataire. Conserver un contrôle total sur la conception doit lui éviter de “se faire avoir” par un prestataire qui possède une maîtrise technologique qui lui échappe. Je ne pense pas que ce soit la principale raison, les outils développés en interne souffrant la grande majorité du temps de cette problématique. J’ai travaillé sur suffisamment d’outils métiers pour me rendre compte de la difficulté d’allier approche métier globale, culture du client, et expertise du développement logiciel chez une seule personne. D’où, peut-être, la méfiance mise en avant par Abhijit Nadgouda, mais également les erreurs commises par les deux parties, faute d’avoir pu englober la totalité du problème. Toute la difficulté pour le prestataire sera alors d’appréhender totalement le métier de son client, et sa manière de travailler, tout en lui montrant en quoi les solutions techniques disponibles vont répondre à ses problèmes, chacun profitant ainsi de cet échange de savoir.

Et vous, vous êtes-vous déjà retrouvé confronté à ce type de situation ? Comment avez-vous réagi ? Comment vous en êtes-vous sorti ?

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: