Et si la solution c’était de développer moins ?

J’ai toujours pensé que les entreprises développaient trop d’applications et pour des résultats peu satisfaisants : beaucoup de projets abandonnés en cours de route, un SI trop encombré par de multiples couches successives, etc.
Au tout début de l’informatique, développer ses propres applications était logique : rien n’était disponible, tout restait à inventer. Les organisations clientes devaient tout développer elles-mêmes avec les moyens du bord. Les outils étaient peu nombreux et peu pratiques, les compétences étaient rares et l’expérience manquait. On ne peut imaginer combien ces pionniers en ont bavé !
Se rabattre sur les progiciels aurait été une option logique, mais ces derniers étaient encore plus rares que les programmeurs !

Une évolution importante : le SaaS
Dès 1998, des éditeurs de logiciels d’un nouveau genre sont apparus : les ASP (pour Application Software Provider). Ces pionniers proposaient d’accéder à des applications directement à travers Internet et avec un navigateur Web comme interface. Finalement, ce n’était qu’une prolongation de la logique inventée par les premiers webmails comme Hotmail.
SalesForce faisait partie de ces pionniers et on peut dire que cette société a complètement redéfini son marché avec son approche du progiciel basée sur un accès simplifié et peu coûteux de son CRM. Progressivement, avec la montée de la notion “d’informatique dans les nuages” (le fameux cloud, vous n’avez pu y échapper), les ASP sont devenus des fournisseurs de SaaS et se sont multipliés. Désormais, l’offre de progiciels en ligne est plus fournie et plus diverse que jamais.
Avec le SaaS, le mouvement aboutissant à « l’Internetisation de l’informatique » était enfin lancé mais on peut voir combien le chemin du progiciel a été long et tortueux.

Toujours trop de “developpements maison”
Et pourtant, en dépit de ces progrès manifestes dans le domaine des progiciels, les entreprises développement toujours trop en interne. Et pourtant, il y a de nombreux inconvénients dans ces projets :

• ça coûte cher,
• c’est long à faire,
• c’est difficile à mettre au point,
• c’est souvent démodé, à peine disponible,
• et surtout, jusqu’à 50% des projets sont des échecs.

Les projets informatiques font face à un taux d’échec ahurissant. Depuis des décennies, malgré le recul qu’on a, les progrès de la technique et des méthodes, ce taux d’abandon ne baisse pas, au contraire !
C’est un problème tellement présent qu’il y a même un cabinet d’études qui s’est spécialisé sur la question : il s’agit du Standish Group.

Chaos report by the Standish Group
Selon un rapport publié en 2015 par ce cabinet qui a sondé quelque 400 organisations, seuls 29% des projets informatiques ont été considérés comme des succès cette année-là, cʼest-à-dire finalisés dans les temps, sans dépassement de budget et avec toutes les fonctionnalités prévues (ces consultants produisent ce même rapport depuis 1994 avec plus ou moins les mêmes taux chaque année…). 19% sont considérés comme des échecs, cʼest-à-dire annulés avant la fin ou jamais utilisés. Les 52% restants ont pris plus de temps et/ou dʼargent que prévu et/ou ont fourni moins de fonctionnalités que prévues.
Il est toujours difficile et hasardeux de dégager une tendance en se basant sur une étude isolée. Le problème cʼest qu’année après année, ce genre dʼétude (menée également par d’autres organisations que le Standish Group) se répète et toujours avec des résultats similaires : le taux dʼéchec des projets informatiques menés par les organisations reste incroyablement élevé !
Et la tendance ne semble pas aller en s’améliorant puisque, dans son édition 2018, le “chaos report” (en voilà un qui porte bien son nom au moins !) du Standish Group établissait que seuls 29% des projets étudiés dernièrement pouvaient être considérés comme des succès…
Donc, on l’aura compris, développer des applications informatiques c’est difficile, coûteux et risqué. Mais alors, pourquoi le fait-on et surtout, pourquoi le fait-on autant ?
Mais alors, comment expliquer qu’autant de gens s’y engagent quand on a compris que c’était des projets très risqués ?

Faire et refaire…
Eh bien pour une raison toute simple : c’est que la propagande, très active dans ce milieu, vous incite à le faire. Tous les médias sont friands d’histoires formidables d’entrepreneurs à succès qui ont atteint leur but grâce à une application développée par leur équipe. L’extraordinaire boom de la téléphonie mobile à lui aussi encouragé le développement d’une nouvelle vague d’applications. Et ça ne s’arrête jamais, il y a toujours une nouvelle mode pour justifier de remettre le couvert.
Ce martèlement va toujours minimiser la difficulté de ce type de projet. On va au contraire vous expliquer que c’est facile, que c’est rapide, que ce n’est pas cher. Toute cette propagande s’appuie sur une mécanique bien huilée, nourrie à la fois de médias, d’experts et d’événements tels que des conférences, tout ça pour promouvoir un mouvement sans fin, qui favorise encore et toujours le développement de nouvelles applications.

Des fonctions jamais utilisées
De plus, le système d’information (SI) des entreprises est déjà largement surchargé avec une bonne partie des fonctions qui ne servent simplement jamais !
En effet, une autre étude du Standish Group établit que presque la moitié, 45%, des fonctions d’un SI ne sont jamais utilisées… Plutôt que de développer des nouvelles applications, les DSI devraient déjà commencer par faire le ménage dans leur existant !

Les péchés capitaux de notre industrie
La personnalisation semble moins carnavalesque que le développement spécifique, mais elle débouche sur les mêmes impasses. Les projets de personnalisation échouent au même rythme que les projets d’écriture de logiciels spécifiques pour les organisations.
Mais cela veut-il dire que tout effort de personnalisation est à bannir absolument, dans tous les cas ?
Non bien sûr, il y a des cas où une personnalisation légère est nécessaire et bénéfique. C’est la personnalisation à outrance qui est à éviter absolument !
« À outrance », qu’est-ce que ça veut dire ?
C’est de faire des développements spécifiques pour contourner les fonctions standards de l’application (celles déjà intégrées par l’éditeur dans le progiciel) afin de pouvoir garder ses propres processus plutôt que de s’adapter à ceux présents dans le package. Si les processus standards ne vous conviennent pas comme ils sont, mieux vaut carrément changer de progiciel plutôt que de se lancer dans une personnalisation en profondeur qui équivaut, le plus souvent à un développement spécifique.
De plus, procéder ainsi, c’est se priver à coup sûr des mises à jour et des évolutions du progiciel proposés par l’éditeur à l’avenir : votre personnalisation à outrance vous a coupé de la version d’origine, pour de bon (pour le pire en fait !).
Les DSI se sont habituées à presque tout faire par elles-mêmes parce que c’était ainsi qu’on pratiquait dans l’informatique depuis des décennies. Mais, à partir des années 2000, les choses ont vraiment commencé à bouger dans ce secteur, des choses importantes qui justifient de changer nos habitudes. Tout d’abord, il y eut le livre de Nicholas Carr “Does IT matter?”. Le livre de Carr a eu de l’impact, car il s’attaquait au caractère sacro-saint de l’informatique : sa supposée importance stratégique. Difficile à encaisser pour ce milieu qui vivait justement grassement sur ce postulat !

Second choc : la montée du cloud et du SaaS
Peu après avoir perdu son caractère stratégique, l’informatique d’entreprise subissait une mutation profonde avec la montée du “cloud”. En effet, l’internetisation de l’informatique (comme je l’écrivais dès 1998) se concrétisa avec l’utilisation massive des ressources accessibles via le réseau (d’où cette appellation “d’informatique dans les nuages”, voir ma chronique à ce propos https://www.redsen.com/chronique-alain-lefebvre/marche-cloud-situation-perspectives-evolutions-introduction/).

Comme l’avait si bien démontré Carr, il n’était pas “stratégique” pour l’entreprise de posséder et d’opérer elle-même ses propres serveurs, les fournisseurs comme Google, Amazon et même Microsoft le faisaient pour bien moins cher, avec bien plus de sécurité et d’efficacité. Cette dématérialisation des ressources s’accompagnait d’un changement de pratique du côté des progiciels : ceux-ci devenaient directement accessibles sous la forme de services dans le cloud (d’où cette autre appellation en vogue : le SaaS ou “Software as a Service”).
Avec le SaaS, plus besoin d’installation technique de logiciels sur vos serveurs : vous souscrivez un abonnement et c’est tout !

L’informatique encourage la paresse !
Le recours au développement spécifique ou à la personnalisation à outrance est le triste résultat d’une paresse intellectuelle qu’on retrouve trop souvent. C’est comme si tous ces dirigeants renonçaient à simplifier leurs organisations en pensant que « l’informatique va permettre de gérer cela », comme si l’informatique était magique… Or, il suffit d’avoir travaillé dans ce domaine pour savoir que cela rime plus souvent avec « tragique » qu’avec « magique »…

Un exemple édifiant avec cet extrait d’un article de Libération (source http://www.liberation.fr/france/2017/11/10/logiciels-de-l-etat- erreurs-systemes-en-serie_1609374) :

Ancien président du Conseil national du numérique et directeur de l’innovation du groupe Open, Benoît Thieulin a travaillé, de 2000 à 2005, au service d’information du gouvernement, où il a assisté à la mise en place du dossier médical partagé. «Ce qui m’a effaré, c’est que même quand on part d’une feuille blanche, on se retrouve toujours après quelques années avec un énorme cahier des charges, explique-t-il. Or entre-temps, le contexte a évolué. Dans certains cas, l’objet est tellement complexe qu’il n’est pas développable.» Sans compter l’appétit peu scrupuleux de cabinets de conseil et autres entreprises de service qui se sont «gavées» sur la bête publique. Autre raison structurelle : le logiciel est vu «comme une solution technique facile pour absorber une complexité qu’on ne veut pas traiter», poursuit Thieulin. Cas d’école : les 174 primes différentes de l’armée française (mal) digérées par Louvois.

Comment faire autrement ?
En dépit de décennies de pratique, d’une succession de méthodes, et d’outils qui se sont améliorés, la programmation ne sera sans doute jamais simple. Et inutile d’attendre une percée fulgurante du côté des environnements de développements (eux aussi en perpétuelle évolution) car, comme l’expliqua si bien Fred Brooks, il n’y a pas et il n’y aura pas de “balle magique” qui, miraculeusement, résoudrait tous ces problèmes d’un seul coup.
Nous venons d’expliquer qu’il ne faut pas se lancer dans des projets de développements informatiques longs et complexes, d’accord. Mais alors, vont dire en cœur les DSI, comment allons-nous faire pour satisfaire les demandes de nos utilisateurs ?
Simple, développer moins, mais développer mieux. Facile à dire, mais cela mérite quelques explications…

Systématiser le recours au SaaS
Tout d’abord, nous l’avons vu lors des chapitres précédents, toutes les demandes ne doivent pas forcément se traduire par un projet de développement d’une nouvelle application, déjà. Sur ce plan, le recours aux progiciels accessibles via le cloud (les fameux SaaS) doit être systématisé. Et, s’il vous plaît, avec le minimum (vraiment le minimum) de personnalisation.

Les micro-applications
Second volet de ma recommandation pour développer moins, mais mieux, les “micro-applications”… Qu’est-ce donc que cela et comment les mettre en œuvre ?
Une nouvelle vague d’environnements de développement d’applications est en plein boom ces derniers temps. Il s’agit des outils dits “low code”. Ils promettent une approche de type “coding léger” (voir pas de coding du tout) et c’est exactement ce qu’il nous faut…
Car nous voulons que nos “micro-applications” soient développées rapidement, très rapidement : dans ce cas, on parle de semaines voire de jours, pas de mois !
Et c’est justement ce que sont nos micro-applications : des projets courts, très ciblés et développés rapidement selon les principes de la méthode “agile”.

La vitesse de développement : un horizon hors de portée ?
Le temps nécessaire pour développer les applications s’est révélé être un problème depuis que les organisations s’y sont lancées !
Depuis tout ce temps, on peut dire que tout a été essayé afin de résoudre ou, au moins, d’atténuer ce manque d’efficacité : méthodes, langages, approches, outils, etc.
Car la vitesse de développement n’est pas seulement souhaitable (qui peut se réjouir de devoir attendre son application pendant des années ?), c’est aussi nécessaire. Tous ceux qui ont travaillé sur des grands projets savent bien que la durée de développement influe beaucoup sur son aboutissement : plus un projet de développement est long et moins il a de chance de voir le jour…
De nombreux syndromes s’accumulent : le syndrome du comité (les spécifications de la future application sont définies par de trop nombreuses personnes qui ont du mal à se mettre d’accord entre elles), le syndrome de l’effet tunnel (déjà vu à la fin du chapitre 6) et enfin, le syndrome du trou noir (le projet capte tout -ressources, budget- sans produire de résultat pour être finalement annulé). Rares sont les grands projets s’étalant sur des années qui parviennent à survivre à tout cela. Donc, pour aboutir, il vaut mieux faire vite.

Low-code ou no-code ?
Ces nouvelles plateformes de développement se présentent comme si facile à utiliser qu’elles ne demandent pratiquement pas de coder pour développer (voir ma chronique à ce propos https://www.redsen.com/chronique-alain-lefebvre/comment-choisir-un-outil-de-developpement-low-code/).

Soyons clairs, aussi faciles qu’elles soient, ces plateformes demandent quand même des compétences techniques non négligeables. Le fait de ne pas devoir coder (ou peu) n’est que la partie émergée de l’iceberg, comme toujours. Des connaissances en matière de base de données et de design d’interface utilisateur sont indispensables afin d’aboutir à quelque chose d’utilisable.
En revanche et ce qui est bien plus important que l’absence de coding, c’est la capacité à aller vite dans le cycle de développement. Au lieu de demander des mois, ces plateformes vont vous permettre de livrer des applications à vos utilisateurs en quelques semaines voire en quelques jours. Cette démarche rapide n’a que des avantages : elle permet le prototypage en de multiples phases si c’est nécessaire (démarche agile). On évite ainsi à la fois “l’effet comité” et “l’effet tunnel” si néfaste à la survie des projets.
Le point clé, c’est vraiment le temps qu’on assigne au projet envisagé. Ici, on doit raisonner en jours/homme ou en semaines/homme. Dès qu’on commence à envisager des durées qui s’expriment en mois/homme, on va droit dans le mur !
Vous devez rester dans une optique de projets courts, c’est absolument essentiel pour la réussite finale. Et des projets courts, ça implique forcément des projets de petites tailles, avec un jeu de fonctions forcément réduit. On va donc développer plusieurs micro-applications (avec répartition des fonctions par domaine) plutôt qu’un gros projet qui contient tout. Ce principe modulaire va avoir son influence sur le choix de notre outil “low code”.

Bases de données et Zapier
En effet, il vaudra mieux que cet environnement soit capable de travailler avec différents types de bases de données plutôt que d’en adresser une seule. Et ce, afin de favoriser la répartition des fonctions sur plusieurs micro-applications tout en étant capable de reposer sur le même ensemble de données. Également, nous aurons besoin d’un moyen de relier les micro-applications entre elles, et en direct si possible !
C’est justement ce qu’offre une nouvelle vague de “middleware Internet” comme Zapier. Zapier est le parfait exemple du middleware du Web qu’on attendait depuis des années (voir ma chronique à ce propos https://www.redsen.com/chronique-alain-lefebvre/les-middlewares-cloud-pour-une-integration-no-code/). Zapier vous offre le lien nécessaire entre des applications différentes qui, normalement, ne communiquent pas entre elles. Et cerise sur le gâteau, c’est super facile à utiliser (no code) !

Arrêtez de vous laisser enfumer par les modes !
Bien entendu, les critiques de cette approche ne vont pas manquer. Certains vont vous dire “ce Lefebvre n’est pas raisonnable, comment peut-on se passer de développer alors que nous sommes en pleine vague du mobile ?”. Faux !
Parlons-en de cette fameuse “vague du mobile” qui justifierait de tout refaire (c’est la “transformation digitale”, vous comprenez…) une fois de plus… Il y a deux ou trois ans, on vous affirmait que, pour être prises au sérieux, vos applications mobiles devaient impérativement être “natives” et être cataloguées dans les app-stores des grands acteurs (Apple et Google). Aujourd’hui, encore un changement de direction, ces applications mobiles obligatoires ne sont plus forcément natives car une dernière tendance a vu le jour et se révèle être la (nouvelle) marche à suivre : les “progressive web app” (voir à https://fr.wikipedia.org/wiki/Progressive_web_app)… Moi je dis qu’il est temps de ne plus se laisser influencer par cette propagande qui change tout le temps son mot d’ordre pour mieux essorer vos budgets !

Une roadmap super-simple
Nous avons nos instructions, simples et précises : des projets courts, un outil low code et l’utilisation de Zapier (ou d’un autre « middleware » du web qui existe aujourd’hui) pour relier les applications les unes aux autres (le workflow à la portée de tous !). En respectant ces principes, vous allez pouvoir reprendre le contrôle de vos projets de développements et satisfaire vos utilisateurs.

Cette chronique est un résumé du livre que je viens de publier dernièrement : Arrêtez de développer des applications

La version Kindle ou la version papier sur Amazon.