L’informatique raisonnée des grands-projets
Les grands projets informatiques ne sont pas un long fleuve tranquille. L’informatique raisonnée », on aurait tout aussi bien pu écrire « raisonnable », est un nouveau concept issu du dernier livre d’Alain Lefebvre, dont le but est justement de réparer les dégâts que l’on constate si souvent autour de ces énormes chantiers informatiques. Les lecteurs qui y auront été mêlés de près ou de loin, nous comprendrons aisément. Nous avons interviewé Alain dans le cadre de notre dossier sur l’environnement de travail du futur. Ceux de nos lecteurs qui le connaissent déjà ne seront pas étonnés, il ne mâche pas ses mots. Mais le co-fondateur de SQLI nous fournit également, au travers de cet ouvrage des pistes concrètes pour améliorer les choses.
L’informatique raisonnée pour mettre fin au « gâchis » des grands-projets
Alain Lefebvre n’a pas de qualificatifs assez durs à l’encontre des grands projets informatiques, autour desquels les désastres se sont succédés. Dans le privé, et surtout dans le public (en fait, ce sont ceux-là qui sont les plus visibles dans la presse). Le livre d’Alain, que l’on trouve sur Amazon n’est pas qu’une critique à charge contre les grands chantiers IT, cependant. Il fournit aussi des pistes de travail — en attendant le prochain livre qui parlera de la mise en œuvre — pour envisager un futur plus doux et plus profitable à l’informatique du futur. Un livre que nous vous résumons au travers de cette interview avec l’auteur.
Le « gâchis généralisé des grands projets informatiques »
Dans mon introduction, j’aborde le gâchis généralisé qui caractérise trop souvent les projets informatiques de nos jours. Peut-être pas seulement de nos jours d’ailleurs … Mais aujourd’hui, il n’y a toujours pas d’amélioration.
Les capacités et les outils se sont améliorés, mais on en réclame toujours plus. On est toujours aussi ambitieux, trop ambitieux. Et deux fois sur trois, ça finit en désastre.
Le cabinet Standish Group, spécialisé dans la mesure des succès des projets informatiques, indique que les meilleures années, la proportion de projets réussis ne dépasse pas 30%
La plupart du temps, ce sont des échecs, voire des désastres. Échec veut dire « n’a pas été conclu dans le temps ni dans le budget imparti ». Désastre signifie que ce projet a été abandonné en cours de route, et cela arrive souvent.
Grands projets IT : des exemples de désastres … sans exagération aucune
J’ai des exemples précis à mettre en avant parce que généralement, on imagine toujours que j’exagère. J’aimerais bien exagérer, malheureusement, je n’invente rien et je n’exagère pas.
Pendant cette décennie, il y a un certain nombre de grands projets de notre glorieuse administration française, qui ont été abandonnés après avoir coûté des centaines de millions d’euros.
Par exemple, Louvois, plus de 400 millions d’euros et SIRHEN, 320 millions d’euros de dégâts. Quant à l’Office national de Paye, le projet a finalement été arrêté en mars 2014, et c’est un gâchis de 600 millions d’euros. Ce sont des exemples précis qu’on connaît, parce que c’est le gouvernement, et les gouvernements sont tenus à une certaine transparence alors que les clients privés le sont moins.
Mais malgré tout, des éléments montrent que généralement, les grands projets informatiques sont des bains de sang. Par exemple, les implémentations de SAP sont abandonnées une fois sur deux [NDLR, c’est même pire, le chiffre exact est 60% d’échecs]. Récemment, LIDL en Allemagne a annoncé qu’il renonçait à sa mise en place de SAP. Et ça leur a coûté plusieurs centaines de millions d’euros. Souvent, les grands projets se terminent mal.
Les petits projets peuvent-ils réussir ?
C’est ça l’essentiel du message de ce livre. Mon but n’est pas d’interdire le développement spécifique, comme certains pourraient le penser. Ce n’est pas ça du tout.
C’est justement de donner sa chance aux petits projets en évitant d’investir toutes ses ressources, tous ses moyens dans des grands projets qui n’aboutissent pas, ne serait-ce que parce qu’ils durent trop longtemps.
Donc, on est victime de l’ « effet tunnel », de l’ « effet comité » et ainsi de suite. On a mobilisé toutes ses ressources sur quelque chose qu’on finit par abandonner. Et du coup, il ne reste jamais rien pour les petits projets plus modestes qui apportent pourtant de la valeur.
Et c’est pour cela d’ailleurs qu’il y a des phénomènes comme le Shadow IT qui se manifestent dans les organisations.
Panorama des tournants de l’IT
La fameuse crise de l’an 2000
L’essentiel de l’informatique de gestion a été, pour les grandes organisations, mis en place et développé dans les années 60, ou au plus tard dans les années 70, et à l’époque, pour économiser de la place en stockage, on n’enregistrait les dates que sur deux digits pour ce qui concernait les années.
[NDLR : 95 au lieu de 1995 par exemple ce qui posait des problèmes une fois qu’on passait à 01 pour 2001 vs 1901]
Evidemment, pour passer d’un siècle à l’autre, ça allait poser problème. Il y a eu cette grosse crise qu’on a appelé la crise de l’an 2000, où il a fallu corriger des centaines et des milliers de programmes à la main pour arriver à faire passer ce problème de date. Bien souvent, d’ailleurs, les corrections n’ont pas eu lieu. Des grandes chaînes de gestion ont été remplacées par des ERP, tels que SAP . Ça a été un grand moment, un âge d’or pour ces éditeurs d’ERP.
Cette crise a été à l’origine d’une rupture de la confiance entre l’informatique et les directions générales. Celles-ci se sont aperçues qu’elles ne pouvaient pas avoir confiance durablement dans leur informatique, puisqu’il y avait des pièges cachés, des bombes à retardement, qui pouvaient se réveiller comme ça à l’occasion d’un changement d’année. Ça a été un gros traumatisme, une grosse rupture, même si, au final, la crise n’a pas été aussi grande que ce qu’on avait envisagée au départ.
Vers 2004 le « IT doesn’t matter » de Nicholas Carr a laissé des traces
Ses analyses sont très intéressantes. Il ne faut pas se contenter de lire ses résumés, il faut lire ses livres. Récemment, il a écrit sur Google, sur la tendance à l’abrutissement généralisé. Ses livres sont formidables. Il a remis en cause une des vaches sacrées de l’informatique, à savoir que les projets informatiques n’étaient pas stratégiques. Mais il faut s’entendre sur la définition exacte du terme stratégique. Le problème, c’est qu’à notre époque, il y a beaucoup de définitions qui sont surexploitées, complètement galvaudées.
Par exemple, les gens emploient le terme « révolution » à tort et à travers, alors qu’il vaudrait mieux utiliser « percée ». C’est plus précis et plus exact.
Quand vous dites « l’informatique, c’est stratégique », il faut entendre que les gens disent « l’informatique, c’est important ». Et là, on est évidemment d’accord.
Quand on dit « c’est stratégique », « c’est un avantage stratégique », ça veut dire qu’on détient seuls un avantage concurrentiel. Or les avantages concurrentiels durables existent peu. À chaque fois, les concurrents peuvent copier votre mise en œuvre d’autant plus rapidement que depuis 40 ans, une des tendances majeures de l’informatique moderne, est de rendre disponible de plus en plus rapidement, toutes les nouveautés.
Les nouveautés sont de plus en plus rapidement largement disponibles et à meilleur coût
Cela ne veut pas dire qu’on dépense moins. On dépense toujours plus pour l’informatique, mais on en a plus pour son argent. C’est tout à fait contradictoire avec l’idée qu’on pourrait se doter d’un avantage qu’on serait les seuls à avoir et qu’on garderait jalousement auprès de soi.
L’informatique stratégique est une croyance
C’est principalement ce que Nicholas Carr a expliqué dans ce qui était d’abord un article et est ensuite devenu un livre. Et c’est ce que j’ai repris dans mon dernier ouvrage. Je m’aperçois que j’ai fait une erreur là-dessus. Non pas que j’ai eu tort sur le plan fondamental, je pense que j’ai parfaitement raison, mais j’ai eu tort sur l’idée de vouloir combattre cette perception. L’informatique stratégique, c’est une croyance. On ne s’attaque pas à une croyance avec des arguments raisonnables, rationnels. Les gens sont persuadés que l’informatique est importante et que ça se traduit par l’adjectif « stratégique ». Ça ne sert à rien de combattre ça.
Au tournant des années 2010, il y a eu le fameux cloud computing, devenu une véritable évidence.
L’importance du cloud computing est incontestable. C’est l’informatique centrée réseau qu’on imaginait déjà dès la fin des années 90, s’est enfin réalisée à travers le cloud, tout simplement pour son côté pratique. Car le cloud vous évite d’avoir à faire des installations, des paramétrages, des mises au point. C’est un service directement opérationnel et accessible à travers votre navigateur Web.
C’est un progrès fantastique et cela explique son succès. Ceci dit, il faut quand même noter que le cloud a mis presque 15 ans à s’imposer. Aujourd’hui, on peut considérer qu’il a gagné la bataille, mais il a quand même fallu du temps.
Dernier tournant important, beaucoup plus récent : le confinement et le télétravail.
Depuis plus d’une dizaine d’années je me demandais pourquoi le télétravail ne s’imposait pas davantage, pourquoi les gens ne comprenaient pas qu’il valait mieux organiser une réunion par vidéoconférence que faire des centaines de kilomètres pour s’enfermer trois quarts d’heure dans une salle climatisée et parler 30 secondes. Il y avait une espèce d’évidence, mais l’évidence ne suffit pas toujours.
Et tout d’un coup, le confinement a comblé l’écart qu’il y avait entre la perception générale et la disponibilité des outils. Tout d’un coup, on a été obligé de se rendre compte que c’était beaucoup plus rationnel, beaucoup plus pratique.
Alors attention, je ne suis pas en train de dire qu’il faut généraliser à tout prix, complètement et pour toujours le télétravail et bannir complètement toutes les réunions physiques, le travail sur des open space ou autres. Je ne dis pas ça. Mais une utilisation rationnelle des outils aurait dû s’imposer depuis longtemps.
C’est en quelque sorte le seul bénéfice qu’on a eu de cette période extraordinaire, extravagante, du confinement. C’est finalement de coller tous les bouts ensemble et de se rendre compte qu’on avait là une corde solide.
Des tournants importants et une proposition dans ton livre de lancer un nouveau concept, une informatique raisonnée
L’informatique raisonnée se décline en trois principes généraux très simples, qui sont faciles à comprendre et à retenir et qui se résument par : lucidité, sagesse, discernement.
1er principe de l’informatique raisonnée : la lucidité
Lucidité, c’est l’informatique critique, et non stratégique. C’est à dire que si vous renoncez à vouloir poursuivre à tout prix un avantage stratégique — ce qui est d’ailleurs vain — vous allez vous concentrer sur des petits projets à valeur ajoutée et ce sera bien mieux pour tout le monde.
2ème principe de l’informatique raisonnée : la sagesse
C’est de comprendre que les projets longs sont des puits sans fin dans lesquels il ne faut pas tomber. Et ça fait très longtemps qu’on dit cela. Les livres de Frederick Brooks dans les années 70 ne disaient rien d’autre (« le mythe du mois-homme »).
3ème principe de l’informatique raisonnée : le discernement
Les modes techniques sont toxiques, ne les suivez pas aveuglément ! On a bien vu ces dernières années les modes se succéder toujours sur un rythme effréné, faire beaucoup de buzz alors que concrètement, ça n’apporte pas grand-chose dans les entreprises. Tous les quatre ans, on se rend compte que la mode était exagérée. On passe à autre chose, sans avoir retenu aucune leçon.
L’informatique raisonnée, c’est justement d’arrêter toutes ces bêtises et d’arrêter tout ce gâchis. En gros, c’est de devenir enfin raisonnable.
En conclusion, pour devenir raisonnable, il faut peut-être arrêter la diarrhée logicielle ?
Oui, absolument. En premier lieu, il faut arrêter d’avoir des ambitions démesurées. Il faut savoir écouter ses utilisateurs. Par exemple, des phénomènes comme le Shadow IT, au lieu d’être négatif, peut être tout à fait mis à profit pour permettre d’identifier ce dont vos directions métier ont réellement besoin.
Elles en ont tellement besoin qu’elles l’ont fait par elles-mêmes. Avec la montée des outils qu’on appelle low-code / no-code, c’est d’autant plus facile que tout est disponible en mode SaaS. Le shadow IT n’est donc pas prêt de disparaître, mais au lieu que ce soit négatif, il faut savoir en tirer parti.
Va-t-on assister à une reconfiguration totale du métier des informaticiens ?
Je ne suis pas inquiet sur le sort des développeurs car on aura toujours besoin d’eux. Je ne remets pas en cause le besoin d’applications spécifiques, mais simplement l’approche « grand projet » pour ces applications spécifiques.
Par contre, pour ce qui est des administrateurs systèmes, c’est un peu différent, car le cloud, justement, remet en cause, au moins en partie, leur spécificité, leur valeur ajoutée.
Il est clair qu’il va y avoir une remise à plat de certains métiers dans l’informatique, mais ça a toujours eu lieu. A chaque nouvelle vague, à chaque renouvellement, il y a toujours eu une remise à plat. De la même façon qu’à une époque, les développeurs Cobol ont disparu, puis on les a rappelés bien vite quand il y a la crise de l’an 2000. Il y a tout le temps ces phénomènes de va et vient.
Ceci dit, la remise à plat va peut-être être plus globale.
C’est le moment de se mettre à l’informatique raisonnée car on est en train de changer d’ère à travers un ralentissement très prononcé des effets de la loi de Moore. Or, il ne faut pas oublier que depuis 40 ans, l’informatique dans son ensemble était comme un train dont la locomotive était justement cette loi de Moore, qui apportait des accroissements de capacités. Pas seulement en termes de puissance de calcul, mais aussi de stockage continu à meilleur coût.
N’y-a-t-il pas aussi, cachée derrière cette informatique raisonnée, une critique de l’abus d’agilité ?
J’aime beaucoup les méthodes agiles et je trouve que c’est un progrès formidable. Et c’est pour ça que j’insiste beaucoup sur le côté très pragmatique de la démarche d’évolution vers l’informatique raisonnée.
Il ne faut pas prendre Agile comme une méthode à suivre à la lettre
Il ne faut surtout pas la prendre comme une méthode dogmatique à suivre à la virgule près. L’agilité a été victime de son succès. Tout d’un coup, les gens se sont mis à embrasser l’agilité sans vraiment bien la comprendre et bien la digérer. C’était la ferveur des nouveaux convertis. Il fallait montrer qu’on était 100% conforme à l’agilité et cela devenait une espèce d’auto parodie complètement ridicule.
Si l’informatique raisonnée a du succès, et je le souhaite, elle permettra d’éviter cet écueil de la rigidité et du dogmatisme.
Les orientations que je mets en avant et les recommandations dans le prochain livre qui va suivre — puisqu’on est en train d’écrire une suite qui va s’appeler « L’informatique raisonnée en pratique » — c’est que tout ça ne doit pas être appliqué rigidement, mais selon votre contexte.
La souplesse d’adaptation des principes, orientations et recommandations de l’informatique raisonnée permettra d’éviter la crise que traverse actuellement l’agilité
A propos d’Alain Lefebvre
Alain a plus de 40 ans d’expérience en informatique. Il a été le co-fondateur de SQLI, pionnier du client-serveur puis du Web. Il se se consacre désormais à l’écriture avec 30 livres publiés depuis le premier en 1993.