Vers une informatique raisonnée

Depuis que je rédige ces chroniques sur les tendances décryptées, nous avons pu passer en revue pas mal de domaines !

Le point commun de la plupart de ces sujets : la propagande technique est toujours en (gros) décalage avec la réalité du terrain. Mais ce n’est pas le plus grave.

Le plus embêtant, c’est plutôt le bilan qu’on peut dresser de l’état de l’informatique professionnelle alors qu’on nous incite à “embrasser la transformation numérique” (encore un terme creux et vide de sens).

Une responsabilité partagée

Et justement, si on dresse ce bilan, il se révèle être sévère : le niveau de frustration et de rejet des organisations vis-à-vis de cette ressource essentielle (l’informatique) est dû aux errements de ces dernières décennies qu’il devient désormais impossible de dissimuler. Entre des projets de développement d’applications en interne qui échouent trop souvent, un héritage (legacy systems) et une dette technique écrasante (mainframes, ERP), cela fait effectivement beaucoup.

Sans compter une insatisfaction générale des utilisateurs (plus ou moins méritée, car il est bien connu que les utilisateurs tendent à se plaindre de leur informatique interne, que ça soit justifié ou non). De plus, on reproche aux services en charge de l’outil informatique d’être également en retard vis-à-vis des dernières tendances (à tort ou à raison, car se jeter sur la dernière tendance à la mode est rarement la bonne chose à faire !).

Avec un dossier aussi lourd, il est clair que l’avocat de la défense va avoir du travail pour faire acquitter son client !

Pourtant, force est d’admettre que l’Informatique des organisations est souvent le résultat d’un empilement de couches qui remontent aux années soixante pour les plus anciennes. Et, de cette accumulation, nous en avons tous été partie prenante : les directions informatiques qui ont subi ce phénomène, les prestataires de services qui l’ont accompagné et les utilisateurs qui, dans leur grande majorité, ont encouragé le mouvement sans comprendre la vraie nature de ce qu’ils étaient en train de mettre en place.

L’informatique raisonnée pour revenir sur terre

Heureusement, pour sortir de ces impasses et de ces ornières, j’ai un concept à vous proposer : l’informatique raisonnée.

Il vous offre une démarche qui s’appuie sur des principes simples et bénéfiques. Cela va vous permettre de reprendre la main sur la ressource informatique de façon sereine et durable.

Trois principes généraux

Un peu comme le manifeste agile avec ses valeurs, l’informatique raisonnée s’appuie sur trois principaux généraux simples à comprendre et à retenir :

Lucidité – L’informatique est critique, pas stratégique.
Sagesse – Les projets longs sont des puits sans fonds dans lesquels il ne faut pas tomber.
Discernement – Les modes techniques sont toxiques, ne les suivez pas aveuglément.

Lucidité, sagesse, discernement, c’est un beau programme, non ?

Riches de ces principes fondateurs, nous pouvons en déduire des orientations solides et légitimes qui vont vous permettre de reprendre la main durablement sur votre informatique…

Quelques orientations à respecter

L’informatique raisonnée peut donc vous apporter de nombreux bénéfices, à condition de respecter les orientations suivantes :

Développez moins, développez courts !
Faites simple, évitez la complexité ou ne faites pas.
Systématisez le recours aux solutions SaaS et résistez à la tentation de (trop) les personnaliser…
Gérez vos risques.
Ne laissez pas des techniciens diriger vos évolutions.
Restez en dehors des modes.

Des orientations à ne pas prendre au pied de la lettre !

Avant de commencer à détailler le contenu des orientations, voici un avertissement important : ces orientations qui suivent ne sont pas des règles absolues qu’il faudrait suivre aveuglément et sans réfléchir, tout au contraire !

L’informatique raisonnée fait justement appel à votre sagesse et à votre discernement, tout le temps. Cette chronique n’est pas écrite par un “maître à penser”, vous devez penser par vous-même pour bien intégrer et appliquer les principes et les orientations de l’informatique raisonnée.

Par exemple, “Évitez la complexité” n’est pas aussi simple qu’il y paraît. Où doit-on mettre la limite ? Comment évaluer la complexité ou la simplicité d’une solution ? Il n’y a pas de réponse absolue et sans ambiguïté à ces légitimes interrogations. C’est pour cela qu’il faut prendre cette orientation comme un “principe directeur”, pas moins et pas plus. Et cela s’applique à toutes les orientations et principes de l’informatique raisonnée, car, avant tout, il faut faire preuve de bon sens afin d’éviter que cette orientation bénéfique soit gâchée par le dogmatisme (tout comme on a pu voir cet effet pervers à l’œuvre dans l’application des principes des méthodes dites agiles…).

Une démarche souple

Permettez-moi d’introduire ici une digression, car c’est important avant d’aller loin dans les orientations de l’informatique raisonnée. Tout comme les méthodes agiles, l’informatique raisonnée est une démarche, une philosophie, une orientation, pas un plan d’action strict et détaillé à respecter à la lettre !

Voyons (rapidement) comment les choses peuvent dérailler (comme s’est arrivé en partie aux méthodes agiles) quand on perd de vue cette nuance fondamentale…

Une critique de l’abus d’agilité

Après avoir été très à la mode, les méthodes dites “Agiles” subissent désormais une vague de critiques, y compris de la part des fondateurs du mouvement.

Ron Jeffries, un informaticien américain de renom dit qu’on devrait abandonner les méthodes Agiles dans les entreprises. Son avis est d’autant plus important parce qu’il est l’un des 17 signataires du Manifeste pour le développement Agile de logiciels. Selon Amir Yasin, cofondateur et CTO de June (société US spécialisée dans le recrutement des professionnels seniors de l’IT), “Agile est devenu tout ce que le modèle Waterfall était pour les développeurs, et pire. C’est un loup déguisé en agneau”.

L’habituel débat entre pragmatisme et dogmatisme

Avec des reproches aussi tranchés, on pouvait penser que la démarche Agile est enterrée pour de bon une fois pour toutes !

En fait, comme souvent, il faut se garder de “jeter le bébé avec l’eau du bain”… Car, selon Ron Jeffries lui-même, ce ne sont pas directement les méthodes qui sont en cause, mais plutôt la manière dont elles sont appliquées. En clair, certaines équipes se sont emparées d’Agile pour se comporter exactement comme avec les méthodes en cascade : avec rigidité, s’imposant d’en respecter la lettre plutôt que d’en comprendre l’esprit. C’est l’habituelle confusion entre pragmatisme (tirer le meilleur d’une démarche) et dogmatisme (obéir aveuglément à des règles qu’on ne comprend pas vraiment).

Ajoutons qu’Agile est également victime de la mode qui l’entoure. En effet, comme il était à la mode d’évoquer les méthodes Agiles, le terme a été largement détourné et déformé. Tout d’un coup, on a vu les équipes IT s’interroger : “Sommes-nous Agiles ?” et puis aussi “Sommes-nous suffisamment Agiles ?” et ainsi de suite. Tout cela commençait à tourner au ridicule et on sentait bien qu’un retour de bâton se profilait à l’horizon…

Car quand quelque chose est populaire (et trop galvaudée), il arrive forcément un moment où cette faveur s’efface pour laisser la place à du ressentiment. Bref, ce qu’on reproche désormais à Agile repose sans doute plus sur des sentiments et des interprétations que sur sa nature réelle.

Pas de dogmatisme avec l’informatique raisonnée

Il est clair que je souhaite éviter un tel destin à l’informatique raisonnée et, pour cela, il vaut mieux prévenir que guérir : les orientations énumérées dans cette chronique sont à appliquer sans rigidité ni dogmatisme. Je répète et je reformule pour être sûr d’être tout à fait clair : appliquez les principes de l’informatique raisonnée avec sagesse et discernement. Voilà, c’est dit, avançons.

Développez moins, développez courts !

Il faut minimiser votre effort de développement en préférant les solutions externes chaque fois que c’est possible (développez moins). Et quand ça ne l’est pas (ça doit rester une exception) on va se permettre de développer des applications spécifiques qui vont être des “micro-app” : c’est-à-dire des projets courts (quelques semaines maximum, pas de mois et encore moins des années !!), réalisés en étroite collaboration avec les utilisateurs (approche agile) et en utilisant des outils no code/low code.

Mais ce n’est pas tout ! Il faut aussi que ces projets restent simples en plus de rester courts. Et pour cela, vous allez devoir “éviter la complexité”…

Évitez la complexité

Tout d’abord, une précision importante : quand j’écris “évitez la complexité”, c’est en direction des solutions à appliquer aux problèmes posés par le monde réel que l’on rencontre au quotidien. Le monde est complexe, les solutions ne doivent pas l’être (ou alors, ce ne sont pas des solutions !).

Tout au contraire, elles doivent être simples pour être utiles et utilisables. Donc, “évitez la complexité s’adresse d’abord et avant tout aux solutions…

La complexité des réponses est trop souvent une excuse pour un effort de conception trop faible. La complication d’un système n’est jamais nécessaire que ce soit sur le plan technique, fonctionnel ou ergonomique. Les solutions les plus performantes, pérennes et efficaces sont très souvent les solutions les plus simples (sans oublier que ce sont aussi les moins coûteuses).

Les experts veulent de la complexité !

Au grand dam des experts qui méprisent systématiquement les techniques modestes pour préférer les propositions sophistiquées, ce sont précisément les solutions les plus simples qui se sont souvent imposées justement parce qu’elles sont simples. Toute technologie a besoin d’un certain temps avant d’atteindre sa maturité. Les performances sont tout juste correctes, et les mises en œuvre des différents vendeurs pas forcément au point. Or plus une technologie est sophistiquée, plus elle va consommer de ressources (et donc impacter les performances), et plus les problèmes de compatibilité seront fréquents. C’est ce qui est arrivé à CORBA. Peu adapté à Internet (surtout à l’époque où la plupart des particuliers en étaient toujours au bas débit) et sujet à de nombreux problèmes d’incompatibilités. CORBA n’a jamais réussi à écorner HTTP qui, avec sa version 1.1, a su résoudre ses problèmes de performance. Parfois, qui peut le plus est incapable du moins.

Tim Berners-Lee a sauvé le Web grâce à son entêtement…

Le Web est un des exemples les plus célèbres où la simplicité triomphe. L’une des critiques récurrentes auxquelles Tim Berners-Lee (TBL) a eu droit dès le début est l’absence de répertoire centralisé de liens. Ceci afin d’éviter le phénomène de liens brisés et la tristement célèbre « erreur 404 ». Il a heureusement persisté. Personne n’aime le problème de liens brisés, mais l’autre alternative (avoir un répertoire centralisé de liens) aurait certainement empêché le Web de se développer comme il l’a fait. En faisant l’impasse sur la gestion des liens brisés, TBL a permis à quiconque le voudrait, de créer sa page Web sans avoir à demander d’autorisation à personne (d’où le développement phénoménal qu’on a connu).

Autre composant du Web génial de par sa simplicité : le langage HTML. L’utilisation d’un format texte pour décrire une page était tout sauf évidente. Au début des années quatre-vingt-dix, on s’orientait vers les environnements graphiques pour décrire la pagination (quoi de plus normal ?) et utiliser un format texte semblait désuet, il a pourtant de nombreux avantages : sa simplicité fait que n’importe qui peut créer des pages Web en utilisant n’importe quel outil et sur n’importe quelle plate-forme… Ça n’est pas rien !

N’importe quelle application écrite avec le langage de votre choix peut facilement générer du HTML. Et comme il est au format texte, on peut également le stocker facilement dans une base de données. Mais simplicité ne veut pas forcément dire limité. HTML est un langage qui contient beaucoup d’intelligence implicite. Tout d’abord, les termes utilisés sont uniquement des termes de pagination. Le langage parle de paragraphe, de tableau et non de widget, de handle et autres termes techniques. Le fait que le HTML ne permette pas une description au pixel près fait que l’on n’a pas besoin de préciser l’emplacement au pixel près des éléments.

Ensuite, si l’on définit un tableau dont la largeur fait 50 % de celle de la page, c’est au navigateur non seulement de déterminer la largeur du tableau en pixels, mais également de déterminer la largeur de chaque colonne suivant le texte contenu. Par comparaison, encore plus de quinze ans après le Web, les environnements graphiques traditionnels vous obligent à élargir vous-même les colonnes d’un tableau lorsqu’elles sont trop étroites, même s’il y a de la place.

TCP/IP ou la promesse du “meilleur effort”, mais pas plus !

TCP/IP est sans doute le meilleur exemple de cette bonne adaptation au monde tel qu’il est alors que les promoteurs de l’OSI voulaient à tout prix cadrer avec ce que devrait être un protocole dans un monde tel qu’on voudrait qu’il soit. La philosophie du « meilleur effort » paraît sûrement insuffisante à certains, il n’empêche qu’elle s’est avérée assez performante et fiable pour s’imposer largement.

L’interface utilisateur, un autre exemple

On vient d’évoquer l’influence du web sur l’interface utilisateur et le gain que sa simplicité a apporté. Mais on a vu également cette force s’appliquer sur les applications mobiles. En effet, le principe de base est on ne peut plus simple (que ce soit pour IOS ou Android) : une icône égale une application et, à l’intérieur de celle-ci, le périmètre fonctionnel est limité (même si les “super app” chinoises sont un peu l’exception à la règle).

Les CubeSat sont en train de devenir la norme

Même dans un domaine aussi pointu et délicat comme le spatial, la simplicité finit par s’imposer. CubeSat désigne un format de nanosatellites défini en 1999 par l’Université Polytechnique de Californie et l’université Stanford pour réduire les coûts de lancement des très petits satellites et ainsi permettre aux universités de développer et de placer en orbite leurs propres engins spatiaux. La norme date un peu, mais son décollage est récent : de quelques unités par an, on en est désormais à quelques centaines de CubeSat qui sont mis en orbite chaque année.

Les satellites les plus simples répondant au standard CubeSat ont la forme d’un cube d’un décimètre de côté (volume de précisément un litre), doivent peser moins d’1,33 kg et utilisent des composants électroniques banalisés (comme les caméras issues de téléphones mobiles).

Même dans ce secteur habitué au sur-mesure, la standardisation et la simplicité sont en train de changer les habitudes.

Les Chromebooks gagnent du terrain

Petit à petit, les Chromebooks (ces ordinateurs portables définis par Google et commercialisés par les fabricants de PC) gagnent du terrain, tant en entreprise que chez les particuliers. Tout bonnement parce que leur simplicité apporte un lot d’avantages qui pèse lourd pour un usage au quotidien. Encore une preuve qu’accepter de faire moins pour faire mieux est un choix gagnant.

Pourquoi une telle obsession de faire complexe ?

L’une des raisons est une déformation professionnelle. Lorsqu’on a un marteau en main, tout ressemble à un clou. Les informaticiens n’aiment pas le bricolage, même quand ça marche. L’autre raison est que plus une solution est complexe, plus elle justifie l’existence d’une organisation.

La simplicité est la qualité “mal-aimée” du milieu informatique, mais ce sont les solutions simples qui résistent au monde réel, s’imposent durablement, changent notre quotidien et nos habitudes… Cependant, il ne faut pas confondre “simple” et “simplification” !

Accepter l’hétérogénéité

En effet, éviter la complexité cela veut aussi dire accepter d’avoir plusieurs solutions pour répondre à un même besoin, quand les périmètres à adresser sont différents… On a trop souvent tendance à vouloir trouver la solution qui réponde à tous les besoins (vouloir être tout pour tout le monde, ça ne marche pas !). Faire cela, ce n’est pas faire simple, au contraire. C’est se retrouver à faire complexe sous prétexte d’une simplification à outrance !

Pour être plus concret, prenons l’exemple vécu d’une organisation qui veut déployer une solution de gestion de dossiers dans l’ensemble de ses services. Ceux-ci vont de 15 à 800 personnes. Leur maturité est bien évidemment hétérogène et, en conséquence, la complexité des sujets à traiter bien inégale. La tentation naturelle dans un environnement centralisé est de faire une étude permettant d’identifier le GRAAL, la solution qui sait tout faire (qui va être, en règle générale, chère et complexe… exactement ce qu’on voulait éviter !). Une fois celle-ci choisie, l’étape suivante habituelle va être de créer un template qui permettra de déployer rapidement la solution pour tout le monde (ça, c’est le souhait du départ, rarement le résultat obtenu à l’arrivée…). Petite digression : le template est à l’intégration ce que le framework est au développement spécifique : une tentative coûteuse et rarement efficace de standardisation… En règle générale la rentabilité de ce type d’initiative se retrouve chez l’intégrateur en charge de la mise en œuvre et rarement chez le client final…

Un exemple typique de projet (trop) long !

Revenons à notre template (nous sommes déjà à M+6 du lancement des réflexions initiales), il va être utilisé pour mener à bien le premier projet. Celui-ci est complexe et assez loin des besoins des autres départements candidats. Une fois ce premier projet achevé (+ 18 mois), il est temps de généraliser la solution et de la diffuser. Bien évidemment, il faut démarrer par une amélioration du template (on a quand même appris beaucoup dans ce premier projet). Voici le moment tant attendu de le proposer à de petits départements (ils sont servis après les autres, car moins visibles…). Passées les premières démonstrations, vient le moment où il faut parler du prix et des délais. Et là, mauvaise surprise (pour celui qui paie), le coût est prohibitif et surtout le temps de mise en œuvre n’est pas proportionnel à la complexité. Eh oui, vouloir faire simple sans prendre en compte le contexte revient à pondre une solution complexe qui, à vouloir convenir à tous, ne contente personne…

La malédiction du comité d’architecture

Deux solutions à ce stade :

Payer cher pour un besoin qui ne va pas être traité de manière optimale,
Ne rien faire (ce qui arrive souvent…).

Pourquoi et comment on en est arrivé là ?

Tout simplement par ce qu’un comité d’architecture a décidé qu’il fallait (à tout prix) une solution unique. Cette vision centralisatrice et jacobine est malheureusement extrêmement bien développée chez nos clients. Ce sont des départements qui sont naturellement centralisateurs, car c’est ainsi qu’ils développent leurs influences et assurent leur survie… Mais ce n’est pas une fatalité !

À l’origine, il n’y avait que le département “qualité et méthode”. Mais, au fil des décennies, il s’est “réinventé” et a fait des petits (le groupe architecture, PMO, qualité, etc.). Ils ont de nombreux points communs :

La moyenne d’âge : Il faut être expérimenté pour y rentrer, y intégrer du sang neuf est risqué (en pratique, ça n’arrive jamais !).
Il est rare d’en sortir (à part à la retraite…).
Ils pratiquent fréquemment le dogmatisme (c’est leur façon d’avoir raison).
Ils ont un avis sur tout et surtout un avis qui se construit à l’aune des nombreux séminaires et lectures des cabinets d’analyse (pas besoin de les citer vous les avez reconnus…), pas en allant sur le terrain (et puis quoi encore ?).
Et enfin, une forte incompréhension des enjeux métiers et des problématiques vécues par les équipes qui délivrent !!!

Il existe heureusement d’autres chemins. Débarrassez-vous de ces îlots de bureaucraties qui ne fonctionnent que pour assurer leur survie (un syndrome classique). Remplacez-les par des initiatives utiles et qui seront bien accueillies.

Par exemple de proposer à ses clients internes, un catalogue de solutions. En fonction du contexte, on sélectionne la solution la plus adaptée aux besoins et aux moyens disponibles. Évidemment, il ne s’agit pas non plus de faire exploser le nombre de solutions à mettre à disposition. Il y a heureusement une nuance entre un SI “monolithique” (qu’il faut évidemment éviter) et un SI “ultra fragmenté” (qu’il faut tout autant éviter !).

Non au SI “stalinien” !

Le système d’information inspiré de l’informatique raisonnée ne doit donc pas ressembler à un système d’information de type “stalinien” (monolithique). La métaphore est osée, mais elle représente assez bien ce que l’on ne veut pas. Au même titre que les blocs bétonnés sans saveur ayant fait l’ordinaire des banlieues soviétiques ne représentent pas le modèle idéal d’urbanisme dans lequel on souhaite vivre, il en est de même pour le système d’information.

Dans la chronique, nous avons déjà développé les limites du SI monolithique.

La simplicité théorique du monolithe (un seul éditeur, c’est plus simple) n’est pas un gage de satisfaction des utilisateurs ni de simplicité de mise en œuvre. Il est parfois plus simple de déployer deux solutions que de déployer une seule solution paramétrée à outrance et enrichie de modules développés en spécifique. Pour illustrer notre propos : une étude de cas avec Lidl, l’acteur bien connu de la distribution “discount”.

Lidl renonce à l’approche monolithique

Cet industriel a fait le choix très tôt d’investir dans SAP pour supporter les fonctions achats, logistiques, finance, RH, etc. Pendant plus de deux décennies il était hors de question pour les décideurs de Lidl de déployer autre chose qu’un module SAP pour supporter les nouveaux besoins métiers. Mais, lorsque le moment d’informatiser les filiales est arrivé (particularité de cette société : la production est concentrée sur plusieurs sites dans un seul pays, mais les produits sont exportés dans le monde entier et il possède en nom propre le circuit de distribution dans ses principaux marchés) SAP a été challengé et, finalement, c’est un autre éditeur (Microsoft) qui a été choisi pour l’informatisation des filiales. Le besoin métier et la simplicité ont pris le dessus sur les diktats des architectes.

Chaque contexte est différent et doit faire l’objet d’une évaluation. Il n’y a pas de réponse juste, mais seulement de bonnes questions à se poser. Seul un questionnement intelligent et structuré permet de trouver le chemin adapté.

Une illustration du besoin de souplesse

Toutes ces précisions sur l’orientation “évitez la complexité” illustrent, si besoin en était, la nécessité d’une certaine souplesse (et du bon sens !) dans l’application des principes de l’informatique raisonnée. Rien ne doit être pris au pied de la lettre, car cela ne mène nulle part si ce n’est dans des impasses. Dans tous les cas, vous devez prendre en compte le contexte afin d’appliquer nos orientations dans ce qu’elles ont de meilleur et pas plus.

Évitez les solutions “à la pointe de la technique”

C’est un peu un complément au principe précédent (évitez la complexité, préférez les solutions simples), mais ça vaut quand même la peine d’enfoncer le clou encore une fois !

Les solutions simples sont les meilleures et elles n’ont pas forcément besoin d’être conformes à la dernière mode, au dernier cri de l’évolution technique… Quand votre problème ne peut être résolu que par une solution “à la pointe de la technique”, c’est que votre problème n’est pas mûr pour se laisser résoudre, voilà tout !

Laissez les dernières innovations techniques aux lanceurs de fusées et contentez-vous des solutions éprouvées. La solution dernier cri ne va pas vous donner d’avantage significatif et la solution aboutie ne va pas vous mettre en retard non plus… Nous l’avons déjà amplement expliqué dans le chapitre précédent (retours décroissants, illusion de l’avantage aux pionniers, etc.), inutile donc de revenir encore dessus.

Utilisez les solutions standards

Quand une solution standard se dégage dans un domaine fonctionnel, il faut l’utiliser, même si elle n’est pas parfaite, car c’est ce standard qui va se généraliser à terme. C’est ce qui s’est passé dans l’e-mail et c’est également ce qui va arriver avec les Wiki dans le KM (Knowledge Management).

Comment minimiser votre effort de développement (frugalité) ?

La mode des années 2010 de l’off-shore était l’exemple typique de la bonne réponse à une mauvaise question (ou l’inverse !) !

En effet, ce qu’il faut pour réduire les coûts des projets de développement d’applications, ce n’est pas faire appel à des équipes en Inde ou en Russie (entre autres), mais développer moins, tout simplement !

L’accès à la frugalité viendra quand les clients renonceront enfin à vouloir personnaliser à tout prix les applications qui leur sont proposées. C’est pour cela que beaucoup de projets ERP se sont révélés si coûteux en bout de course, parce que les clients voulaient ceci ou cela (souvent pour faire semblant de prendre en compte les aspirations de leurs personnels, pas vraiment pour répondre à un vrai besoin) et c’est parce qu’en face, il ne se trouvait personne pour leur dire “non, c’est une mauvaise idée, laissez le progiciel comme il est” et pour cause !

Pour les sociétés de conseil et les prestataires de services informatiques, cette customisation excessive des ERP était du pain béni… même si c’était absurde sur le plan conceptuel.

D’une façon générale, le réflexe de développer soi-même plutôt que d’utiliser ce qui existe est un mauvais réflexe. Développez moins, vous vous porterez mieux !

OK, facile à dire, mais comment faire ? Ne plus accepter aucune demande de nouvelle application de la part des utilisateurs ?

Évidemment non, car il existe une solution alternative, c’est de recourir au SaaS.

Systématiser le recours au SaaS

Tout d’abord, toutes les demandes d’application venant des utilisateurs ne doivent pas forcément se traduire par un projet de développement. Sur ce plan, le recours aux progiciels accessibles via le cloud (les fameux SaaS) devrait être systématisé. Et, s’il vous plaît, avec le minimum (vraiment le minimum) de personnalisation.

Disons-le une fois de plus, mais le recours à la personnalisation, c’est le réflexe de la paresse, le manque d’effort pour s’adapter à l’organisation que propose le progiciel en standard. Or, l’expérience prouve qu’il est plus facile d’habituer les équipes à une nouvelle façon de faire que de réussir une personnalisation en profondeur.

Pour vous aider à démarrer dans cette démarche, voici quelques ressources :

Il y en a sûrement plein d’autres, je me suis contenté de quelques recherches rapides pour déjà trouver cela… à vous de continuer à creuser, je suis sûr qu’il y a quelque part une solution qui va vous convenir. Le domaine du Saas est en pleine croissance, je serais vraiment surpris que vous me disiez “j’ai regardé et il n’y a rien !”…

Les microapplications pour le spécifique

Mais quid des problèmes spécifiques, vraiment spécifiques ?

Eh bien, pour ces cas-là (qui vont forcément être plus rares que les cas génériques), on peut avoir recours aux microapplications… De quoi s’agit-il ?

Ce sont des projets qui peuvent être menés en quelques jours voire quelques semaines. Dès qu’on dépasse un mois, ce n’est déjà plus une microapplication, point. Et pour développer dans cette timebox très réduite, il faut avoir recours à des pratiques radicales : choisir des outils no-code (ou low-code), utiliser des méthodes agiles et tirer parti des nouveaux middlewares du Web comme Zapier.

Low-code ou no-code ?

Ces nouvelles plateformes de développement se présentent comme si faciles à utiliser qu’elles ne demandent pratiquement pas de coder pour développer. Dans la plupart des cas, c’est bien vrai, mais cela veut-il dire qu’on peut se passer de développeurs ?

Cette question agite les esprits puisque, aux USA au moins, on commence à parler de citizen developers…

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 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 (plus sur ce sujet : Comment choisir un outil de développement “Low-code”).

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éfastes à la survie des projets.

Tout cela vous parait peut-être un peu utopique, mais si on veut rompre avec les démarches traditionnelles (des projets longs et coûteux) et leurs résultats calamiteux désormais bien connus, il faut prendre un tournant radical. Les moyens de ce tournant sont disponibles, utilisons-les.

Puisqu’on parle de démarches traditionnelles, profitons-en pour s’attaquer au trop fameux “schéma directeur” ! De quoi s’agit-il ?

Les directions informatiques avaient la mauvaise habitude (elle n’a pas encore totalement disparu !) de payer très cher quelques consultants issus de cabinets réputés afin de rédiger un “plan d’orientation général des développements” (une définition approximative de la notion de “schéma directeur”).

La question du schéma directeur

Quand on parle de développements spécifiques, certains vont répondre “schéma directeur” comme s’il s’agissait d’une évidence !

En vérité, le passé récent, comme plus ancien, nous révèlent que cette pratique du schéma directeur a souvent fait plus de mal que de bien à la réputation des directions informatiques… Pourquoi ?

Souvent, ce plan d’ensemble était composé de deux parties : un volet fonctionnel (analyse des besoins et des demandes afin de déterminer les applications qu’il fallait développer) et un volet technique (définition d’une architecture informatique et réseau capable de supporter les applications envisagées et les choix des outils pour les développer).

Il fallait des mois pour établir ce plan qui, à peine publié, était déjà dépassé par l’évolution de la technique et par l’évolution des demandes des utilisateurs. Lorsqu’enfin on tenait le précieux document, on pouvait passer à l’examen des demandes et à la mise en œuvre des projets. Et là, une fois encore, on repartait pour un nouvel “effet tunnel” : rien ne voit le jour pendant un certain temps et quand l’équipe émerge avec son application, le contexte a encore changé !

Un schéma directeur raisonnable, c’est-à-dire court !

Bref, on voit bien ici que le schéma directeur pratiqué ainsi est l’équivalent informatique du “plan quinquennal” cher aux régimes communistes des années soixante : beaucoup de prévisions glorieuses et bien peu de réalisations concrètes… Le seul schéma directeur raisonnable, c’est celui qui est bouclé en quelques semaines et qui peut être révisé tous les semestres (un “schéma directeur agile” donc !).

Enfin, un point important à traiter quand on envisage des développements spécifiques : en interne (house programming) ou en sous-traitance ?

Privilégier le house programming peut sembler être une bonne solution à court terme, mais elle implique de gérer ses développeurs au quotidien (il s’agit d’un personnel qui doit être motivé si on veut les garder…), de leur fournir du travail en permanence (et des projets motivants, de préférence !) et de leur offrir des perspectives de carrières intéressantes… Pas forcément facile à concilier tout cela quand le cœur de l’activité de votre organisation n’a rien à voir avec l’informatique !

Donc, la solution du développement en interne est à réserver aux grandes organisations qui ont les moyens d’avoir ce type de collaborateurs en permanence… Pour les autres, voyons ce qu’implique le recours à des sous-traitants.

Les intervenants extérieurs demandent à être suivis de près

Les intervenants extérieurs demandent à être suivis de près sinon, ça peut vite coûter cher sans vraiment produire de résultats. Donc, attention aux régies à longue durée qu’on finit par perdre de vue (le syndrome du ou des collaborateurs externes qui finissent par se fondre dans le paysage !). Attention aux projets mal définis qui partent (souvent) en vrille et finissent en contentieux.

La bonne recette est sans doute de combiner une équipe réduite en interne (des chefs de projets compétents techniquement, de préférence), mais dotée de capacitées élevées de manière à pouvoir encadrer et contrôler les intervenants extérieurs (quand on sait de quoi on parle, il est plus difficile de vous faire avaler des salades !).

Une fois de plus, je suis obligé d’enfoncer le clou et de rappeler un point important : on développe d’autant mieux qu’on développe peu…

Autre point important pour s’assurer de rester frugale en matière de développements internes : les utilisateurs. Or, ceux-ci vous montrent ce qu’ils veulent vraiment grâce à ce qu’on appelle désormais le “shadow IT”…

Tirez profit du “shadow IT”

Le shadow IT est vu comme un cancer par les tenants de l’informatique traditionnelle qui vont, avec des trémolos dans la voix, vous affirmer que ces “pratiques cachées” (et pourquoi pas “honteuses” pendant qu’on y est ?) mettent en danger la cohérence du système d’information.

Laissons ces imprécateurs avec leurs terreurs injustifiées et proposons plutôt une approche positive de ce phénomène. Les utilisateurs de votre organisation se mêlent de développer leurs propres applications ? Et alors, n’est-ce pas ce que l’on veut, et ce depuis des décennies ?

Rappelons que la naissance de ce qu’on a appelé “l’infocentre” dans les années 70 était justement vu comme une façon de soulager le service informatique naissant…

Ressuscitez l’infocentre ?

Donc, il ne s’agit pas de ressusciter l’infocentre ancienne manière, mais plutôt d’encourager et d’accompagner les utilisateurs quand ils sont capables d’identifier un besoin et de développer une application avec l’outil de leur choix. Au pire, ce “développement” pourra toujours servir de prototype et de cahier des charges pour une réalisation plus sérieuse dont votre service (ou votre prestataire attitré) se chargera le cas échéant.

Donc, oui, le shadow IT est une tendance dont on peut tirer parti dans le cadre de l’informatique raisonnée plutôt que de vouloir la combattre. D’une façon générale, “faire la guerre aux utilisateurs” est la pire dérive de l’informatique traditionnelle et précisément ce qu’on veut éviter de reproduire avec l’informatique raisonnée.

Une opportunité réelle d’encadrer enfin le shadow IT

L’émergence d’une offre conséquente de solutions Low Code / No code propose aujourd’hui une possibilité réelle d’encadrer le shadow IT. Il y a une opportunité à ne pas manquer d’offrir un environnement sécurisé et gouverné par la DSI à ses utilisateurs. En effet, ces solutions permettent (merci les technologies web) d’avoir un environnement centralisé (SAS ou sur site) pour supporter le développement et l’exécution des applications ainsi réalisées. Un environnement centralisé et sécurisé, c’est important si l’on souhaite éviter que des données sensibles se promènent de manière anarchique sur les laptops des utilisateurs.

La DSI se concentre donc sur la mise à disposition des services d’accès aux données de référence (API, …) et aux services de sécurité (droits d’accès, …). De leur côté, les métiers sont libres de créer eux même leurs microapplications (au sein d’un environnement qui est administré par la DSI). Charge à la DSI de choisir le bon environnement (voir même plusieurs…) et d’assurer son déploiement et son maintien en conditions opérationnelles. De manière optimale, elle devrait également assurer la formation et l’accompagnement de ses supers-utilisateurs. Pas d’inquiétude, il restera toujours du travail à valeur ajoutée pour les informaticiens car il faudra souvent reprendre et compléter les microapplications ainsi obtenues.

Nous pourrions paraphraser Confucius qui aurait dit “Quand un homme a faim, mieux vaut lui apprendre à pêcher que de lui donner un poisson” en reformulant la fameuse citation ainsi : Quand un utilisateur à un besoin, mieux vaut l’accompagner à construire lui-même son application que de la faire réaliser par un tiers…

Gérez vos risques

Plutôt que de chercher à tout prix un avantage “stratégique” hypothétique en choisissant des solutions sophistiquées ou en développant vos applications en interne, vous devriez plutôt porter vos efforts sur la gestion des risques. Souvenons-nous que l’informatique est critique et qu’il est donc indispensable que ces multiples ressources continuent à être disponibles et fonctionner.

Par exemple, utiliser une application extérieure via un fournisseur SaaS présente des risques, mais, plutôt que d’écarter cette solution à cause de ces risques, gérez-les !

Les zones d’ombres du SaaS

Je ne vais pas essayer de vous faire croire que tout est idéal dans le monde des logiciels en ligne. Le plus gros inconvénient du SaaS est que l’entreprise cliente est très dépendante du prestataire. D’une part ce dernier peut augmenter les prix sévèrement et brutalement (ça arrivera forcément quand le marché va passer par ses prochaines phases de maturité). D’autre part le service peut s’arrêter brusquement. Soit le prestataire arrête le service (Google Reader est un exemple, parmi d’autres), soit le prestataire met tout simplement la clé sous la porte (comme Nortel).

Mais, en dépit de ses inconvénients (réels), je recommande tout de même d’avoir recours aux services du Cloud et au SaaS plutôt que de tenter (vainement, la plupart du temps) d’essayer de faire aussi bien que ces éditeurs. Le triomphe du cloud c’est aussi et d’abord celui de la mutualisation. C’est imbattable quand vous devez choisir de faire avec efficacité et économie. Même avec des efforts et de la volonté, vous ne ferez pas mieux qu’Amazon, que Microsoft ou Google quand il va s’agit de bâtir un data center. Pareil pour les dispositifs de sauvegarde et ainsi de suite, la liste est longue et il vain de vouloir égaler le niveau de performance atteint par les géants de la mutualisation informatique, c’est perdu d’avance.

À vous donc de gérer au mieux la relation avec les fournisseurs en ligne : ne prenez pas tout chez le même afin de vous laisser une marge de manœuvre qui peut (qui va) se révéler utile par la suite.

Multicloud et autres redondances

Le recours au cloud est en train de se généraliser et même les plus réticents commencent à y réfléchir. C’est une bonne chose, car le principe de mutualisation est toujours gagnant : les leaders du cloud ne font pas autre chose que de la mutualisation en mettant leurs ressources géantes à notre disposition. Or, comment imaginer que vous pourriez faire aussi bien qu’AWS, Microsoft Azure, Google ou même OVH en matière de coûts et de performances pour gérer des serveurs à distance ?

Ceci dit, même ces nouveaux acteurs dominants ne sont pas à l’abri d’une panne. Il faut donc gérer le risque cloud, tout simplement. Comment ?

En utilisant la redondance. Les disques RAID présentent une fiabilité et une disponibilité très au-dessus de la moyenne grâce à ce principe de redondance. Eh bien, faisons de même au niveau supérieur : pour éviter d’être paralysé par la défaillance d’un fournisseur du cloud, utilisons-en plusieurs à travers la notion de multicloud.

Le multicloud est caractérisé par l’utilisation de plusieurs services de cloud computing et de stockage dans une seule architecture hétérogène. Cela se réfère également à la distribution des actifs cloud, des logiciels, des applications, etc. à travers plusieurs environnements d’hébergement cloud. Avec une architecture multicloud typique utilisant deux ou plusieurs clouds publics ainsi que plusieurs clouds privés, un environnement multicloud vise à éliminer la dépendance à l’égard d’un seul fournisseur de cloud.

Mais il ne faut pas se contenter du multicloud, il faut aussi avoir un niveau de redondance au niveau de votre accès Internet lui-même. Si votre fournisseur d’accès Internet est subitement défaillant (et ça arrive tout de même de temps en temps, même pour les plus grands noms), il faut pouvoir compter sur un substitut que vous allez pouvoir utiliser sans délai. Oui, cela revient à payer deux fois, mais la sécurité est à ce prix. Les disques RAID présentent aussi cet inconvénient : leur capacité de stockage réel n’est que la moitié de leur capacité de stockage physique (dans le cas du RAID 1, le plus courant), mais quand on a goûté à la tranquillité d’esprit que ce dispositif amène, on ne revient plus en arrière !

Ne laissez pas les techniciens diriger vos évolutions

Enfin, une autre orientation importante pour rester dans le cadre de l’informatique raisonnée le plus longtemps possible : les techniciens sont de bons serviteurs, mais de mauvais maîtres… En clair, les profils techniques sont utiles et même indispensables pour faire tourner votre informatique. Cependant, ce ne sont pas eux qui doivent décider des choix structurels.

Les techniciens sont comme les enfants : ils aiment s’amuser avec des jouets. Et plus les jouets sont coûteux et exclusifs et plus ils sont contents !

Pour oser un parallèle avec la politique, ce sont des civils élus qui décident des choix militaires les plus importants, pas les militaires eux-mêmes. Car, comme le disait Clemenceau “la guerre, c’est une chose trop grave pour la confier à des militaires”…

Gardez cela en tête quand vous convierez des techniciens à donner leurs avis lors du prochain choix à faire. Certes, avoir un minimum de compétences techniques n’est pas inutile, mais on doit pouvoir décider en dehors des seules considérations techniques sinon vous allez toujours vous retrouver à prendre la solution la plus haut de gamme et donc la plus chère sans que ça soit toujours justifié.

Restez en dehors des modes

Je le répète à longueur de chroniques et d’ouvrages (à tel point que je pourrais passer pour un affreux rétrograde !), mais l’intérêt des organisations qui utilisent l’informatique n’est pas de suivre les modes imposées par les acteurs du marché qui, dans un bel ensemble, sont tous d’accord pour mettre en avant une nouvelle lubie tous les quatre ans.

Rappelons encore une fois que les nouvelles techniques mettent du temps à devenir pleinement opérationnelles (loi du délai incompressible), qu’il faut souvent deux vagues pour obtenir ce résultat et que l’illusion de l’avantage au premier ainsi que la persistance des retours décroissants fait qu’il est inutile de se précipiter : tout le monde va être servi de la même façon et va en tirer le même bénéfice (sauf si votre précipitation vous a incités à vouloir jouer les cobayes !).

Un exemple ? Avec joie !

La transformation digitale était annoncée il y a quelques années comme une rupture majeure. Cloud, objets connectés, big data, intelligence artificielle et même les drones devaient devenir des technologies omniprésentes et tout révolutionner. En parallèle, de nouveaux entrants devaient s’imposer sur le marché avec leurs modèles d’affaires alternatifs et bousculer l’ordre établi, désintermédiant les acteurs historiques.

Dans la pratique, il y a bel et bien eu des ruptures sur certains secteurs d’activité comme Tesla dans l’automobile, Space X dans l’aérospatial, Revolut et N26 dans la banque de détail ou encore Netflix et Spotify, qui ont effectivement révolutionné l’industrie de l’Entertainment. Les GAFAM et BATX sont quant à eux devenus les premières capitalisations boursières et ont provoqué de profondes adaptations réglementaires sur le plan fiscal et en matière de protection des données personnelles, qui ont des répercussions sur l’ensemble des secteurs d’activité.

Mais il est clair que cette transformation digitale si elle a bien eu lieu dans quelques secteurs est loin d’avoir provoqué la rupture majeure tous azimuts annoncée et répétée sur tous les tons.

En somme les ruptures annoncées se sont produites dans quelques cas emblématiques et mis en avant ad nauseam par les thuriféraires de la trop fameuse transformation digitale (elle aussi bien trop mise en avant !). Donc, on a généralisé quelques exemples exceptionnels en voulant faire croire qu’ils pouvaient s’appliquer à tous et dans tous les domaines (ce qui n’était évidemment pas le cas, la suite l’a prouvé).

Les modes techniques sont souvent toxiques

En réalité, c’est la même chose sur le plan technique : ce que les GAFAM peuvent faire n’est pas forcément généralisable à toutes les organisations utilisant l’informatique (loin de là !). Un exemple éclairant avec l’IA : les GAFAM ont tous su mettre en application le machine learning de façon spectaculaire, mais, en dehors de ces cas extrêmes, c’est le désert !

On serait bien en mal de citer des organisations « ordinaires » ayant pu produire des résultats extraordinaires avec les dernières techniques de l’IA à la mode… Même IBM s’est fourvoyé en voulant commercialiser (trop tôt) son programme Watson auprès des intervenants du système de santé américain… Et cette précaution ne se limite pas à l’IA, il en est de même pour quasiment tous les domaines à la mode !

Par charité, on évitera de poser les questions qui fâchent comme “mais où sont donc les voitures autonomes qu’on nous avait promises ?”.

Si c’est pas sexy, ça ne m’intéresse pas !

Le comble est que les modes techniques occupent tout l’espace disponible, obscurcissent les esprits et empêchent les vrais progrès de se développer pendant ce temps-là. Un exemple avec la RPA (voir à ce propos Le RPA ou Robotic Process Automation, un grand avenir !).

Bref, vous l’aurez compris, les modes techniques sont toujours présentées trop tôt et vous avez intérêt à “laisser passer votre tour” afin d’en profiter une fois la maturité arrivée.

Un cap, pas une destination

Rappelons encore une fois les enseignements des principes que nous venons de présenter :

C’est une démarche, pas un dogme !
La simplicité est une vertu, pas une tare.
Développez moins !
Uniquement des projets courts et inspirés du terrain (shadow IT).
Gérez vos risques, ne laissez pas “l’informatique critique” vous mordre !
Passez votre tour, il y a toujours une autre mode…
Les techniciens ne sont pas les payeurs, donc, pas les décideurs…

Gardons en tête “C’est une démarche, pas un dogme”, car cela va mettre en perspective la nature profonde de l’agriculture raisonnée : ce n’est jamais terminé, c’est un cap, pas une destination et c’est donc un travail au quotidien. Il n’y a pas une et une seule bonne façon d’appliquer l’IT raisonnée, mais autant qu’il y a de terrains, car tout dépend toujours du contexte.

Reprendre ses esprits grâce à l’informatique raisonnée

Parmi les nombreux bénéfices apportés par l’informatique raisonnée, le fait de pouvoir “reprendre ses esprits” n’est pas le moindre.

En effet, vous allez vous libérer vous-même de la pression de la nouveauté, du battage médiatique et de la pensée unique comme quoi nous vivons “l’accélération de la transformation digitale” !

Vous allez pouvoir concentrer vos capacités de développement uniquement sur les exceptions qui en valent la peine (développez moins, développez court, développez juste !) et gérer vos risques. Ainsi, votre informatique sera de nouveau à votre service et pas le contraire.