Ce que j’ai appris en 45 ans d’informatique

Je travaille dans l’informatique depuis 45 ans (eh oui !). J’ai commencé en 1977 dans un contexte où les mainframes étaient rois et où les PC commençaient tout juste à émerger (et il fallait vraiment s’y connaître pour les voir venir !). Durant cette période, j’ai pu évoluer, progresser, comprendre deux ou trois choses et me rendre compte que tout cela pouvait finalement bien être utile. Dans cette chronique (cette dernière chronique, voir à la fin…), je vais tenter de vous résumer ce que j’ai appris en 45 ans de pratique et d’observations.

Commencer par les projets

Commençons par examiner l’aspect projets. La plupart des informaticiens sont impliqués dans des projets auxquels ils participent, voire quelquefois les gèrent… Et c’est clairement dans ce contexte qu’on en apprend le plus !

1- Peu importe la méthode employée, ce qui compte, c’est la qualité du chef de projet (et l’inverse est vrai aussi : il suffit d’un mauvais chef de projet pour gâcher le talent d’une bonne équipe).

La mode actuelle est à l’agilité. Mot magique qui est censé tout résoudre mais il suffit d’avoir un peu d’expérience pour savoir que la méthode compte peu (quel que soit le mérite effectif des approches agiles que je ne nie pas, au contraire, elles ont ma préférence mais leur poids n’est pas aussi grand qu’on voudrait le croire…) alors que la personnalité et le charisme du chef de projet compte beaucoup dans le succès de chaque projet. Les méthodes employées n’ont pas cessé de changer depuis des décennies mais sans que cela fasse une grosse différence sur le terrain. En revanche, c’est comme pour les bons développeurs (on y reviendra), les bons chefs de projet, eux, font la différence, c’est clair.

Le rôle de chef de projet n’est pas une sinécure (et je sais de quoi je parle : j’ai joué ce rôle plusieurs fois…) : interface, chef d’orchestre, négociateur, planificateur, le chef de projets doit savoir tout faire, savoir parler à tous, identifier les urgences, savoir comment les traiter et motiver les troupes tout le long du processus tout en sachant gérer le “client” jusqu’à la délivrance (le mot n’est pas trop fort) de l’application.

Combien de fois ai-je vu des projets s’enliser dans des querelles techniques ou dans des imprévus simplement parce que le chef de projet n’avait pas les épaules nécessaires pour apaiser les disputes ou amoindrir les effets des événements imprévus ?

À l’inverse, j’ai vu des situations difficiles s’éclaircir grâce au sang-froid du chef qui su tenir la barre tout en gardant un œil sur le planning. Le bon chef de projet va également être capable d’obtenir des concessions du client au moment critique pour simplement pouvoir terminer le projet dans de bonnes conditions. Car, aussi extraordinaire que cela paraisse, il faut rappeler que les projets réussis sont beaucoup, beaucoup plus rares que les projets qui se soldent par des échecs : dépassement des délais ou dépassement du budget, le plus souvent les deux quand le projet n’est pas tout simplement annulé en cours de route (cas encore plus fréquents qu’on ne voudrait l’admettre). Dans ma carrière, c’est simple, il m’est arrivé plusieurs fois de rencontrer des collègues qui n’avaient jamais été associés à un projet réussi (mais qui avaient beaucoup subi ces projets qui tournent mal). Les vrais chefs de projets sont une ressource précieuse : sachez les identifier, rejoignez-les ou soignez-les mais, surtout, gardez-les.

2- La malédiction de la pyramide : les projets “pharaoniques” se terminent toujours mal (c’est la taille du projet qui se révèle être critique).

On vient de voir l’importance des bons chefs de projets mais même eux ne peuvent rien contre le piège du “puits à goudron” (dès qu’on y met la main, on se salit, on ne peut plus s’en débarrasser…) que représentent les grands (trop grands !) projets. Si vous voulez être sûr de rater votre coup, la recette est simple : prenez un objectif critique, planifiez son exécution sur plus d’un an (à partir de deux ans, vos chances d’échouer augmentent radicalement !) et enfermez une équipe dessus… Laissez mijoter quelques mois, changer le chef de projet en cours de route (le premier est déjà usé…) et attendez que le projet soit finalement annulé pour “raisons politiques”. En effet, si vous combinez “l’effet tunnel” avec la pression du résultat, alors vous êtes sûr d’échouer à tous les coups !

J’ai beaucoup écrit sur ce sujet (les trop gros projets) car j’ai pu constater leurs effets délétères encore et toujours. Décider de lancer un grand projet flatte l’égo au début mais le rêve tourne vite au cauchemar dès que le principe de réalité reprend ses droits…

Toutes les approches de type “big bang” et “révolutions internes” sont vouées à mal se terminer (le plus souvent) dans les domaines techniques. Je l’ai constaté, je l’ai vécu, j’essaye d’avertir contre cette approche “pharaonique” (on va bâtir une pyramide géante avec une pelle et un seau…) et je vais continuer à le faire.

3- Les utilisateurs ne savent pas vraiment ce qu’ils veulent (mais ce n’est pas une raison pour faire n’importe quoi).

Ah, combien de fois ai-je entendu ce cri du cœur : la vie (la nôtre, celle des techos) serait bien plus simple s’il n’y avait pas d’utilisateurs !

À ce cri, il aurait été honnête de répondre “oui mais il n’y aurait pas de boulot pour nous non plus…”. Bref, les utilisateurs sont difficiles à satisfaire pour de multiples raisons : ils ne savent pas vraiment ce qu’ils veulent, ils ne savent pas se servir correctement des outils (comprendre “pas comme nous”) et ils en demandent toujours plus (et ça veut dire “toujours trop”).

Alors, oui, c’est vrai, les utilisateurs ne savent pas décrire avec précision leurs besoins et s’expriment trop souvent en termes de solutions (“faut que votre application fasse ceci ou cela”… vous reconnaissez la situation, n’est-ce pas !). Mais justement, cette difficulté spécifique fait partie de notre “valeur ajoutée” : développer une application est un art difficile qui ne se limite pas à sa partie technique. Il faut aussi comprendre ce qu’il convient de faire qui peut éventuellement être un peu éloigné de “l’optimum théorique” mais conviendra mieux à la population concernée. Lors de la phase de conception, il faut savoir définir l’enveloppe fonctionnelle de manière réaliste tant sur le plan technique (ne pas être trop ambitieux) que sur le plan ergonomique (ne pas faire quelque chose qui vous plait à vous mais plutôt une application qui va être utilisable par les utilisateurs, les vrais…).

D’où le point suivant concernant l’interface utilisateur…

4- L’interface utilisateur est souvent incomprise et toujours négligée (et vous aurez du mal à convaincre vos équipes d’en prendre soin).

Voilà un débat qui n’est pas près de se clôturer : les informaticiens sont-ils sensibles à l’ergonomie de leurs applications ?

La plupart du temps, la réponse est non, hélas. Pour la grande majorité des développeurs, les utilisateurs ont juste le droit d’utiliser l’application telle qu’on l’a définie et si l’interface ne leur plait pas, c’est pareil !

Tout au long de ma carrière, j’en ai vu des vertes et des pas mûres à ce sujet : depuis les interfaces super-spartiates (une aide en ligne ? pourquoi faire ?) jusqu’aux “sapins de noël” les plus burlesques (plus ça clignote, mieux c’est !). Pour beaucoup, passer du mode caractère sur un seul écran à la fois aux multi-fenêtres et au mode graphique, c’était déjà trop… Alors, le Web et le mobile, vous comprenez, hein…

À leur décharge, il est vrai qu’il est difficile d’être bons à la fois en coding et à la fois en design d’interfaces. Mais le plus surprenant est le dédain affiché par beaucoup vis-à-vis de cette question qui s’avère pourtant cruciale. Trop souvent, des applications sûrement bonnes (sur le plan technique) ont été rejetées parce qu’elles étaient négligées voire totalement ratées sur le plan ergonomique.

Un bon test pour savoir si votre interface utilisateur est bonne ou pas : si vous avez besoin d’expliquer quelque chose, c’est que c’est raté (c’est comme pour une blague en fait…).

5- Faire simple est sûrement ce qui est le plus difficile (mais ce n’est pas une raison pour ne pas essayer).

Le premier impératif en matière d’usabilité (c’est cette affreuse expression qui a fini par s’imposer quand on évoque l’ergonomie et les interfaces utilisateurs…), est de faire simple ce qui, je l’ai vérifié souvent, n’est pas facile, justement.

Pour que l’interface reste simple, il faut que les options du moment soient limitées (du coup, les choix possibles sont plus faciles et rapides à déterminer et à décider). Mais tout se complique lorsque le contexte fonctionnel est large. Il faut alors présenter les options progressivement en fonction du parcours de l’utilisateur (de ces choix précédents donc) tout en lui permettant de changer d’avis, de revenir en arrière ou de choisir plus tard (tout en conservant ce qui a déjà été fait…). On comprend tout de suite que “faire simple” n’est que l’apparence : sous la surface, ça devient vite très complexe !

J’ai été confronté à ce paradoxe maintes et maintes fois et je confirme qu’il est délicat de bien s’en sortir. Cependant, il est important que nous nous efforçions de faire mentir l’adage qui serait le favori des informaticiens : “pourquoi faire simple quand on peut faire compliqué ?”. Je suis persuadé que cette désinvolture a beaucoup pesé sur notre image auprès des utilisateurs. Faire simple est difficile, certes, mais il faut quand même s’y atteler car c’est pour notre bien, à tous.

6- Les bons développeurs sont une race à part (mais ne sont pas faciles à gérer !)

On a évoqué les chefs de projets, parlons maintenant des développeurs. Il en existe de trois sortes. Tout d’abord il y a les “fonctionnaires”, les plus nombreux (hélas) : ceux qui font cela pour manger et qui n’éprouvent aucune passion pour leur travail. Ceux-là sont de médiocres développeurs (au mieux) : il faut les éviter car ils polluent les équipes avec leur mentalité de “moins j’en fais, mieux je me porte”… Ensuite, nous avons les “passionnés” : ils aiment coder, ils aiment leur travail et ils sont curieux, toujours prêts à essayer des approches nouvelles, conscients que le coding est une route sans fin. Ils sont malheureusement moins nombreux que les “fonctionnaires” : ceux-là, il faut les avoir dans votre équipe car ils sont travailleurs avec une bonne attitude (c’est important, l’attitude, souvent plus que la compétence arrogante !). Enfin, il y a les artistes, les virtuoses, les Mozart du coding. Ceux-là sont rares, très rares mais vous les reconnaissez du premier coup d’œil : ils sont différents, ils font la preuve de leur don sans avoir besoin de frimer. Les virtuoses sont tellement efficaces qu’ils peuvent remplacer à eux seuls une armée de développeurs médiocres et même une bataillon de bons codeurs (mais sans plus). Il faut l’avoir vécu de près pour se rendre compte du potentiel de ces développeurs exceptionnels. C’est une rencontre qui laisse des traces : vous ne pouvez jamais oublier ce que vous avez constaté et vous restez après cela persuadé à vie que un de ces individus vaut plus que dix, cent, mille de ces semblables mais moins doués.

Ceci dit, il s’agit d’individus qui ne sont pas “faciles à manager” : conscients de leur don, ce sont plus des “franc-tireurs” que des “team-players” et c’est peu de le dire. Le développeur virtuose a besoin de challenges excitants et ne vas pas se fouler si vous lui proposez des travaux ordinaires indignes de son talent. Ceci explique aussi pourquoi ces “perles rares” sont souvent des indépendants et s’intègrent mal dans des équipes constituées de membres plus “ordinaires”…

Passons des projets à la technique

Finissons cette partie dédiée aux projets en insistant encore sur le côté “aventureux” des projets informatiques… Les projets sont difficiles à planifier, difficiles à mener et difficiles à achever. Donc, choisissez-les bien car vous aurez peu de cartouches à brûler !

Parlons technique maintenant. Les informaticiens sont des techniciens et sont tous très fiers de leur maîtrise technique, de leur jargon, de leurs blagues de techos et ainsi de suite. Mais je me suis aperçu que la façade n’était pas aussi lisse qu’on voudrait le croire : propagande et mensonges sont monnaie courante dans ce microcosme.

7- Les grands acteurs du marché ne sont pas de bons indicateurs (ce qu’ils disent est sans influence réelle à long terme).

Les grands acteurs du marché (comprendre, les acteurs dominants) sont très loquaces sur leurs stratégies et leurs visions d’avenir. Que ce soit IBM hier ou Microsoft (ou Google ou Amazon) aujourd’hui. Mais les leçons du passé m’ont révélé que ces discours étaient sans intérêt car sans importance : ce qu’annonce tel ou tel grand acteur est seulement en fonction de son agenda interne et ils sont tous notoirement aveugles (ou, au mieux, myopes) quand il s’agit d’anticiper l’avenir, encore plus sur le long terme.

L’innovation, la vraie, celle qui compte et qui influence la technique, vient rarement des grands acteurs mais plutôt des startups et des communautés travaillant sur des projets open source. Si vous voulez avoir une idée de quoi demain sera fait, n’écoutez pas les discours convenus des GAFAMs mais intéressez-vous aux signaux faibles de ceux (les petits, les obscurs, les sans-grades) qui veulent vraiment changer les choses.

Combien de fois ai-je dû analyser les annonces grandiloquentes de tel ou tel éditeur ou constructeur pour me rendre compte, moins de deux ans après, que tout cela était déjà vain et oublié… L’innovation technique ne se plie pas aux envolées des powerpoints des responsables marketing et c’est tant mieux !

8- Le code ne rouille pas (et les couches techniques s’accumulent).

Nous sommes tous plutôt intéressés par les nouveautés. Les techniques bien établies ne nous excitent pas autant, naturellement. Pourtant, j’ai pu me rendre compte que le patrimoine applicatif et les infrastructures reposent sur du code écrit il y a longtemps avec des langages que l’on considère désormais comme “traditionnels”. Il y a ainsi d’énormes volumes de codes qui tournent quotidiennement et qui font que notre monde fonctionne (à peu près…). Aux yeux des zélotes de la nouveauté à tout prix, ce code est “vieux”, moche, à refaire… Mais c’est faux. Le code “ne rouille pas”, il reste parfaitement valable. En fait, plus vieux il est, meilleur c’est : ça veut dire qu’il est passé (avec succès) à travers tous les types de tests, les changements de configurations et ainsi de suite.

Il faut bien l’admettre une bonne fois pour toutes : les couches techniques qui se succèdent ne s’annulent pas (la nouvelle prenant soi-disant la place de l’ancienne), elles s’accumulent, nuance… Et vouloir refaire ce qui a déjà été fait est non-seulement vain, c’est surtout une erreur qui serait tragique : on risque de remplacer du code fonctionnel, testé et re-testé par du code certes plus moderne mais dont on ne sait rien et dont la fiabilité est un gros point d’interrogation. Heureusement, cela n’arrivera pas : la tâche est presque au-delà du possible (du moins, avec nos moyens actuels… quand les machines sauront coder, là, faudra voir…).

Bref, voici ma recommandation : le code “moderne” doit être réservé aux nouvelles applications, laissez les “vieilles” applications tranquilles, tant qu’elles fonctionnent.

9- Les évolutions prennent du temps (on va encore dire que je me répète !).

C’est quelque chose que j’ai constaté vers le milieu de ma carrière et dont l’importance n’a cessé de se confirmer depuis lors : les évolutions techniques, les vraies, prennent du temps pour se faire. En fait, plus de temps qu’on ne le croit (bien plus même) et plus de temps que ce qu’on est prêt à admettre.

Prenons un exemple : si vous affirmez qu’il faudra au moins dix ans pour que le véritable Metaverse se concrétise, personne ne vous croira, personne n’est prêt à patienter dix ans et, pourtant, vous êtes quand même en dessous de la vérité (indice : il faudra plus de dix ans, bien plus). Cet écart entre la réalité du rythme des évolutions et la perception humaine est bien connu (y compris par nous-même) mais il n’empêche qu’il est toujours à l’œuvre pour déformer notre capacité à évaluer les durées nécessaires. Même moi, je me fais avoir régulièrement sur ce plan.

Si vous expliquez que les évolutions ont besoin de décennies pour se développer (avec des séries d’allers et retours, des hauts, des bas, des périodes d’oublis, des effets de mode et ainsi de suite), vous passerez pour un rigolo ou, au mieux, pour un indécrottable pessimiste (je le confirme !). Et pourtant, c’est vrai. Toutes les leçons du passé, y compris les plus récentes, nous l’apprennent encore et encore : les révolutions en une nuit n’existent pas, elles demandent vingt ans de maturation souterraine pour exploser brutalement en fin de cycle.

10- Tout est cyclique (et les mêmes causes produisant les mêmes effets, il y a tendance à une certaine répétition…).

J’ai eu du mal à l’admettre mais j’ai bien été obligé de faire face à cette réalité : tout est cyclique en matière technique informatique. Il y a des périodes où on va centraliser les traitements et ensuite on va faire le contraire pour de nouveau remettre la barre au centre un peu plus tard. Il y a des moments où les progrès les plus réguliers finissent dans une impasse (loi de Moore) pour repartir de plus belle dans une autre direction (quantique ?), pour un nouveau cycle.

Des moments où le coding est remis en cause puis d’autres où les codeurs sont de nouveau valorisés… Et ainsi de suite. La technique suit une trajectoire complexe qu’il est difficile de visualiser depuis notre point de référence, comme des épicycles. Même le côté “éternel retour” est difficile à anticiper de par la nature de cette trajectoire. Et pourtant, avec assez de recul on s’aperçoit qu’il n’y a rien de complètement nouveau. Une idée qui arrive avant son temps est simplement mise en sommeil avant de renaître quand les conditions sont enfin devenues favorables. Un exemple ?

Volontiers !

En ce moment, l’IA est à la mode depuis que le machine learning a remis le connexionnisme au goût du jour (les progrès techniques en termes de capacité de traitement ont permis à cette déjà vieille idée de prendre enfin son envol !). Mais il est facile d’imaginer que, tôt ou tard, ça sera de nouveau au tour du symbolisme de prendre sa revanche et de revenir dans la course. L’IA basée sur le traitement symbolique est actuellement dans la phase basse de son cycle mais il est facile de prévoir que ça ne va pas durer toujours et que la phase haute va remettre en lumière ce mode de traitement (quand ? ah ça, c’est une autre histoire !).

Allez, encore un exemple pour finir sur cette histoire de cycles. En ce moment, nous nous interrogeons pour savoir quelle forme (éventuelle) va revêtir le Metaverse dont on parle tant et, surtout, quand va-t-il apparaître pour de bon ?

Je ne suis pas en mesure de répondre à ces deux questions avec précision (déçu ?) mais je peux imaginer qu’on va avoir droit à un scénario qui ressemblera de près à celui de l’avènement des réseaux sociaux : une idée beaucoup débattue avant sa concrétisation, quelques acteurs qui font des percées fulgurantes avant de rentrer dans le rang aussi vite (vous vous souvenez de MySpace ?) et, pour finir, un acteur qui s’impose et ramasse la part du lion. Ceci dit, avant que cela n’arrive, l’idée même du Metaverse peut connaître une éclipse plus ou moins longue avant de ré-émerger pour de bon (rappel, les évolutions prennent du temps…).

Pour finir, sachons reconnaître ce caractère cyclique des évolutions techniques jusque dans les détails les plus anodins : en dépit des progrès fonctionnels continus, ce sont quand même toujours les mêmes les mêmes types d’applications qui reviennent périodiquement. Par exemple, les messageries interactives (ICQ hier, Whatsapp aujourd’hui) ou même les forums (comment expliquer autrement l’actuel succès de Discord ?). Bref, sachez distinguer ce qui change avec le temps (pas mal de choses) ce qui reste quasi-immuable (encore plus de choses finalement comme la résistance humaine au changement justement !).

11- Les bugs sont inévitables (et les pires sont dormants).

Un programme ou une application sans aucun bug, ça n’existe simplement pas. Vous trouverez toujours des gens pour vous assurer que tel ou tel programme, telle ou telle application est totalement “clean” mais soit ils mentent, soit ils s’illusionent… Tout simplement parce qu’un programme informatique est hautement dépendant de la configuration sur laquelle il s’exécute. Les bugs peuvent venir de partout : des couches logicielles sous-jacentes (système d’exploitation, drivers, interfaces diverses, etc.) ou même des éléments matériels employés. Pire, tout cela bouge avec le temps. Imaginons une configuration super-clean au départ. En évoluant (en vieillissant donc), elle va se complexifier : plus de systèmes à supporter, plus de nœuds réseaux à interfacer et ainsi de suite, vous voyez l’idée. Donc, même si à T0 votre programme est béton (ce dont je doute, rappel), il ne le restera pas. C’est comme si l’entropie concernait aussi les programmes informatiques !

On peut toujours trouver des bugs : il suffit de chercher suffisamment longtemps et en creusant profondément (l’imagination, la capacité à utiliser le programme autrement que ce pour quoi il a été créé au départ aide beaucoup également…), ça finit toujours par arriver. Des détails en apparence anodins et inoffensifs peuvent se révéler de redoutables portes d’entrées pour des détournements et des plantages… des bugs quoi.

Cela a toujours été le cas depuis les débuts de l’informatique mais la situation, au lieu de s’améliorer, est en train d’empirer : tout le monde est en train de réaliser que le logiciel est un élément essentiel dans les systèmes modernes. Le premier à l’avoir affirmé est Marc Andreessen dans son célèbre article “le logiciel mange le monde” en 2011 (lire à Why Software Is Eating the World). Et, effectivement, tous les systèmes développés désormais contiennent systématiquement une part de logiciel, part de plus en plus importante.

Après la version optimiste contenue dans l’article d’Andreessen, il est temps de passer à la version réaliste : le logiciel est de nouveau en crise parce que sa généralisation démontre son instabilité. La liste est longue des bugs rencontrés par ces “nouveaux consommateurs de logiciels” (constructeurs automobiles ou d’avions, entre autres). On pourrait en faire une énumération, mais c’est inutile : tous les secteurs sont concernés, oui, tous !

Voici un court florilège d’articles attestant de cette nouvelle situation :

• https://www.lenetexpert.fr/les-voitures-promises-aussi-a-des-bugs-logiciels-et-des-mises-a-jour-le-net-expert-informatique/ 
• https://www.automobile-propre.com/embourbee-dans-les-problemes-logiciels-la-volkswagen-id-3-pourrait-decaler-sa-sortie/ 
• https://www.numerama.com/tech/604412-boeing-737-max-un-nouveau-probleme-logiciel-a-ete-repere-dans-lavion.html 

Que ce soit VW ou Boeing, leurs déboires avec les logiciels qui gèrent leurs voitures ou leurs avions font régulièrement les titres des journaux. Les professionnels de l’informatique sont habitués à rencontrer des bugs (et à tenter de les corriger…), mais, cette fois, la nature même de ces bugs est différente.

En effet, il ne s’agit plus simplement d’ordinateurs isolés ou fonctionnant en réseau… Cette fois, on touche du doigt la limite induite par la toujours délicate intégration de systèmes. Pour commencer, ces logiciels s’exécutent dans des contextes où les tests et les corrections sont difficiles à réaliser à cause de la nature même des systèmes embarqués (allez donc traquer un bug qui ne se manifeste que dans certaines conditions d’un avion en plein vol…). Ensuite, les systèmes en question ne sont pas des éléments isolés (comme le sont les ordinateurs, qu’ils soient en réseau ou non), mais bien des éléments profondément dépendants des autres systèmes qui les entourent et les alimentent en données et mesures. Enfin, les organisations qui développent ces logiciels ne sont pas spécialisées en informatique, mais font cela en plus de leur domaine d’expertise habituelle. Tout cela explique, au moins en partie, pourquoi ces bugs sont si fréquents, si bloquants et si difficiles (et coûteux !) à corriger.

J’écris “en partie” car je pense que cette situation est significative d’un nouveau contexte. Il ne s’agit pas d’un épiphénomène qui apparaît brusquement pour disparaître une fois qu’on en aura pris la mesure. Je crois au contraire que c’est juste le début de nos difficultés en la matière. Il est possible, voire probable, que ce type de logiciel ne soit jamais totalement fiabilisé (tout comme il reste toujours des bugs dans nos programmes habituels). Dans le secteur informatique, on s’est adaptés à cette réalité souvent pénible, quelquefois douloureuse, mais qu’on sait inamovible. Dans les secteurs industriels cités, en revanche, je doute qu’on s’attende à une telle non-fiabilité et qu’on n’ait pas encore réalisé qu’elle était quasi-impossible à améliorer radicalement.

La situation ne va donc pas se bonifier, mais va empirer et le logiciel va devenir le facteur bloquant de l’évolution vers le toujours plus d’intégration et de fonctions intelligentes tout comme il a représenté le goulot d’étranglement des débuts de l’informatique.

Passons de la technique au management

Après avoir disserté de la technique (une matière importante dans notre secteur !), il est temps de se pencher sur un autre versant crucial de l’informatique : le management.

En effet, je me suis rendu compte que même les meilleurs développeurs ne pouvaient rien face à une direction inepte. Vous l’avez tous vécu : il est pénible d’être managé (et commandé !) par des médiocres. Or, cela arrive aussi en informatique comme dans tous les secteurs…

12- Le management est à la base de tout (et il est responsable de tout).

La règle d’or est simple : le management est à la base de tout et il est responsable de tout (de l’ambiance aux résultats). On l’a déjà vu avec les chefs de projets, quand quelque chose va de travers, c’est de sa faute (et l’inverse est aussi vrai !). 

Oui, il faut le dire, l’affirmer et le reconnaître, c’est toujours la faute du management quand l’équipe broie du noir ou que les résultats sont médiocres (et c’est toujours son mérite quand tout va bien). Les mauvais managers sont toxiques, peuvent pourrir les meilleurs talents et les projets les plus intéressants. Pire, ils sont bien plus nombreux qu’on ne veut bien l’avouer. Pourquoi ?

Tout simplement parce que ça demande un somme de talents très particulière d’être un bon manager et encore plus en informatique où il vaut mieux ne pas être une “bille” question technique (ou alors, vos techniciens vont s’empresser de vous faire avaler n’importe quoi mais ça sera de votre faute, encore une fois !). Bref, fuyez quand vous êtes sous les ordres d’un mauvais manager (en plus de vous pourrir la vie, il va vous faire perdre votre temps… or, une carrière se décide quand vous êtes encore jeune et, dans ce cadre, le temps est ce que vous pouvez vous permettre le moins de perdre !).

13- Le recrutement doit être pointilleux (dans le doute, abstiens-toi).

Au cas où vous seriez un manager (ou en passe de le devenir), un seul conseil : soignez le recrutement. On dit souvent que “les chefs médiocres engagent d’encore plus médiocres qu’eux…” et c’est complètement vrai (hélas) !

C’est pourquoi vous vous devez d’être particulièrement pointilleux lors du recrutement. Les diplômes et les références ne doivent PAS être vos seuls critères, l’attitude et l’envie sont aussi importants, sinon plus. Donc, si sur ces plans (attitude et envie) vous avez le moindre doute à propos d’un candidat (ou d’une candidate), abstenez-vous, point. Vous allez me dire “facile à dire, alors qu’il n’a jamais été aussi difficile de recruter des bons profils !”. Ah bon, j’ignorais que ce fut facile un jour !

En vérité, les bons profils sont difficiles (et ont toujours été difficiles) à recruter parce qu’ils ont le choix, tout simplement (c’est légitime, ce sont les bons profils, remember…). Mais c’est justement pour cela qu’il faut se concentrer sur les bons : s’ils choisissent de travailler avec vous, ils vont le faire pour de vrai, s’investir et obtenir des résultats parce que c’est d’abord bon pour eux, CQFD.

Au contraire, il n’y a rien à attendre des médiocres et des traîne-savates : ils sont juste là pour faire le nombre et vont vous entraîner vers le bas, issue fatale à éviter à tout prix !

J’ai eu la chance, lors de mon parcours, de pouvoir recruter des bons et même des très bons profils. Aujourd’hui, je constate avec satisfaction qu’ils ont tous fait une belle carrière et qu’ils appliquent eux aussi ce principe majeur : focalisez-vous sur les bons.

14- Ȇtre DSI est une position très difficile, très délicate, (vous êtes entre le marteau et l’enclume).

Si on évoque l’informatique et le management, on pense forcément à la DSI !

Soyons clair : être un DSI est le poste le plus difficile qui soit. Pour les utilisateurs, vous n’en faites jamais assez (d’où le shadow computing) et pour la direction générale, vous dépensez toujours trop !

Tous les DSI que j’ai rencontrés étaient continuellement en train de jongler avec ces contraintes contradictoires et j’en profite pour les saluer : ceux qui s’y connaissent savent que vous faites au mieux dans un contexte super-difficile. Bravo à vous, continuez.

Concluons avec quelques généralités

Après avoir traité tous ces sujets spécifiques, je voudrais finir par deux considérations d’ordre plus générales mais importantes (à mes yeux).

15- La nature profonde de la technique informatique est mal connue, mal comprise (et ce par les informaticiens eux-mêmes…).

Cette constatation est sans doute la plus surprenante de toutes !

Pour un domaine technique où ses membres sont fiers de leurs connaissances (au point de paraître arrogants et inaccessibles aux autres), la vérité est un peu moins reluisante. Ce que j’ai constaté au fil de ces décennies est assez décevant : les informaticiens ont peu de culture de leur propre domaine et une connaissance très vague de son histoire dans le meilleur des cas. En vérité, tout cela les intéresse peu car ils sont intimement persuadés qu’il n’y a rien à gagner en creusant dans ces directions. 

Pour faire bonne mesure, rappelons que tout l’édifice informatique, dont nous sommes si fiers, repose entièrement sur les progrès constants de l’électronique et que le logiciel, lui, peine à s’améliorer dans le même temps. Les processeurs d’aujourd’hui reposent toujours sur l’architecture définie par Von Neumann (qui remonte à 1945 !) mais vous aurez du mal à trouver un développeur qui sache cela ou même qui connaisse (même de nom !) I’illustre John Von Neumann, un des esprits les plus influents de son temps (et pourtant bien moins connu qu’Alan Turing par exemple).

Cette absence d’intérêt pour la culture de leur propre domaine chez les informaticiens m’a toujours étonné et peiné mais il s’est toujours confirmé. 

16- La propagande est omniprésente dans l’informatique avec des effets toxiques évidents (et certains ne se privent pas d’en profiter !).

Avec ce point-là, on déborde un peu de l’informatique mais, suivez-moi jusqu’au bout et vous allez voir qu’au fur et à mesure que notre domaine s’est développé, nos mauvaises pratiques ont commencé à déborder sur les autres secteurs.

Si, comme je le prétends, la propagande technique excessive est toxique, c’est qu’elle devrait avoir des effets mesurables, non ?

Justement oui, et dans ce cadre, je vous propose d’évoquer les fraudes techniques qui se transforment inévitablement en scandales financiers retentissants. Non, il ne s’agit pas d’évoquer les bricolages minables d’un Madoff en 2009 ou les innombrables scandales politiques qu’on ne sait plus dénombrer tellement ils sont fréquents. Intéressons-nous plutôt à la recrudescence récente des fraudes hi-tech afin de comprendre ce qu’elles révèlent sur notre époque.

Les fraudes à grande échelle venant d’entreprises réputées ne sont pas un phénomène nouveau. Il y a eu l’énorme scandale Enron en 2001 (voir à https://fr.wikipedia.org/wiki/Enron) et bien d’autres auparavant, avec de très nombreux cas de comptes bidonnés (d’Oracle en 1991 à Worldcom en 2002, voir à https://fr.wikipedia.org/wiki/WorldCom). Plus proche de nous, il y a eu la surprenante affaire Wirecard en 2020 (voir à https://fr.wikipedia.org/wiki/Wirecard) qui a démontré que même les Allemands n’hésitaient pas à frauder quand l’occasion leur en était donnée. Mais ça, on le sait depuis la gigantesque affaire du dieselgate de WV (voir à https://fr.wikipedia.org/wiki/Affaire_Volkswagen). Puisqu’on évoque des peuples soi-disant vertueux, n’oublions pas nos amis japonais qui ne sont jamais les derniers à se retrouver honteux devant leurs malversations diverses : Toshiba en 2015, Mitsubishi Motors en 2016 et j’en oublie certainement plein d’autres !

Ce qui est nouveau, c’est le caractère technique des scandales récents (à part Wirecard et encore…). Il s’agit essentiellement de mensonges sur les performances techniques de produits mis en avant, pas sur le trucage des comptes comme avec l’affaire WeWork et autres ainsi qu’on en avait l’habitude.

Cette fois, il ne s’agit pas d’entrepreneurs trop “optimistes” sur leur capacité à vendre leur dernière trouvaille, il s’agit de la trouvaille elle-même qui n’est que du vent et ça, c’est (relativement) nouveau.

Ces dernières années et dans ce cadre, nous avons eu l’affaire de Theranos (avec Elizabeth Holmes, voir à https://korii.slate.fr/biz/vilains-du-net-theranos-elizabeth-holmes-scandale-silicon-valley-medecine-mensonge), celle de OneCoin avec la “crypto-queen” bulgare Ruja Ignatova (aujourd’hui toujours en fuite, voir à https://fr.wikipedia.org/wiki/OneCoin), les robots de livraison soi-disant autonomes de Kiwibots (voir à https://siecledigital.fr/2019/09/03/les-robots-kiwibots-etaient-pilotes-par-des-colombiens-sous-payes/) et enfin récemment NiKola Motors (voir à https://www.novethic.fr/actualite/finance-durable/isr-rse/nikola-motor-l-autre-tesla-s-effondre-en-bourse-sur-fond-de-promesses-douteuses-149032.html) avec leurs camions électriques, mais, hélas, dépourvus de moteur (filmés en train de dévaler une colline, ça aide quand on n’a pas de moteur !!). 

Revenons rapidement sur le cas Wirecard. Même s’il ne s’agit pas d’une fraude technique en soi, il y a tout de même une composante hi-tech dans cette affaire. Le PDG de Wirecard (Markus Braun) aimait mettre en avant le caractère innovant de son approche avec, disait-il, une utilisation intensive de logiciels IA de type machine learning… Bien entendu, quand son château de cartes s’est écroulé, son soi-disant recours au machine learning est apparu pour ce qu’il était : un rideau de fumée. Il n’y avait pas d’usage de l’IA à Wirecard autrement que dans les prétentions du PDG.

Tout cela commence à faire beaucoup. Il semblerait que la pression permanente exercée sur les entrepreneurs les pousse de plus en plus à annoncer des résultats inatteignables et à faire semblant de les avoir atteints par tous les moyens (le fameux « fake it until you make it », soit “faites semblant jusqu’à ce que vous y arriviez pour de bon”). Mais dans les cas que nous venons de lister, il semble que la perspective d’y arriver après avoir beaucoup essayé soit même absente…

Les individus nommés ici ont un comportement pour le moins étonnant : ils démarrent quelque chose dont une personne sensée sait qu’elle ne pourra pas s’en sortir. C’est une chose de monter une gigantesque arnaque ou tu disparais dans la nature après avoir plumé quelques pigeons (ou de nombreux pigeons, au choix), mais lorsque tu as ton visage dans tous les magazines de business présenté comme le nouveau Steve Jobs au féminin, tu sais que tu auras nulle part où te cacher (encore que, Ruja Ignatova y est bien arrivé, elle !). Ces comportements quasi-suicidaires sont-ils de plus en plus fréquents ou est-ce l’évolution globale de notre société qui leur permet d’apparaître et de prospérer (au moins pour un temps) ?

On se retrouve avec différents profils de menteur technique avec ces histoires. Voici une typologie dressée sur le tas :

– Nous avons tout d’abord le classique « Fake it ’till you make it » déjà évoqué : des entrepreneurs qui ont peut-être plus de pression ces temps-ci pour offrir des résultats spectaculaires et qui peuvent bidonner des résultats pour gagner du temps. Exemple type : Elon Musk qui aime beaucoup promettre, mais qui oublie rapidement ses promesses (sauf que Tesla a un vrai produit et est finalement devenu profitable). Ou même Bill Gates (qui a promis un BASIC pour l’Altair 8800 -lors des débuts historiques de Microsoft- alors qu’ils ne l’avaient pas encore écrit).

– Nous avons ensuite les business model bidon du style WeWork. Rien d’illégal dans la mesure où ça ne semble déranger personne (sauf que WeWork a fait perdre beaucoup d’argent à pas mal de gens…).

– Nous avons aussi les traditionnels exploiteurs de buzz, comme toutes les compagnies soi-disant d’IA qui n’ont rien à faire avec l’IA sauf dans leur dépliant marketing. Admettons que cette forme de marketing (complétée par des produits merdiques) ait toujours existé.

– Et enfin (je l’ai gardé en dernier !), nous avons le redoutable « Fake it, period » (je fais semblant, point-barre) : les véritables arnaques du style Theranos, OneCoin ou Nikola Motors. Peut-être bien que ses personnages hauts en couleur sont des cas cliniques qui ont toujours existé, mais qui, pas de chance, trouvent peut-être des investisseurs plus réceptifs ces temps-ci et c’est bien cela le problème.

Comment expliquer que des profils pareils et des comportements du type “fake it, period” puissent faire illusion (au moins pour une période) dans notre contexte de capitalisme débridé ?

Il a certes la pression permanente sur les entrepreneurs pour annoncer du grandiose (genre le Web3 pile en ce moment…), mais il y a aussi des investisseurs qui sont prêts à croire n’importe quoi sans vraiment d’esprit critique et sans analyse sérieuse (surtout sur le plan technique) de ce qui leur est présenté : leur fameuse “due diligence” se résume trop à vérifier que les slides soient percutants et que le business plan soit alléchant, peu importe que tout cela soit tissé avec des liens éthérés.

Mais si encore il ne s’agissait que de financiers trop avides. Dans le cas de Nikola Motors, par exemple, il semble bien que General Motors (oui, le fameux constructeur automobile américain, un des premiers au monde) se soit associé (dans tous les sens du terme) avec cette start-up dans un grand enthousiasme, mais sans vraiment vérifier (y compris sur le plan technique qui est pourtant censé être leur point fort…) ce qui leur était dit.

Un tel laisser-aller a des conséquences catastrophiques pour tout le monde et d’abord pour ceux qui s’efforcent de rester honnêtes : ils sont refusés, repoussés, n’arrivent pas à attirer l’attention, car les menteurs pathologiques leur volent la vedette.

Avec une perversion endémique de ce type, on en arrive à encourager le mensonge et à décourager l’honnêteté. Les responsables ?

Tout d’abord les médias qui veulent toujours du sensationnel et ne peuvent se contenter d’améliorations incrémentales (alors que la technique évolue toujours pas à pas). Ensuite les financiers qui sont trop gourmands et qui vont plutôt se tourner vers ceux qui promettent la lune, peu importe que ça soit inaccessible puisqu’ils (les investisseurs des premiers tours) seront sortis du capital de la start-up au moment de l’introduction en bourse et avant que le scandale n’explose… le bon vieux “après moi le déluge” de Louis XV est toujours d’actualité !

Pour finir, revenons à l’informatique en évoquant un enfumage en règle qui a lieu en ce moment même : le Web3 (ce qui prouve effectivement que la propagande excessive a des effets toxiques, ah mais !).

La réaction habituelle des gens normaux est de dire “Le Web3 ? Qu’est-ce que c’est encore que ça ?”… Eh bien, personne ne sait vraiment ce qu’est ou pourrait être le Web3 sinon qu’il n’a rien à voir avec le Web 3.0 mis en avant (sans succès) par Tim Berners Lee. En gros, les promoteurs du Web3 promettent un Web renouvelé et débarrassé de ses tares (comprendre la prééminence des GAFAM) grâce à un fonctionnement décentralisé s’appuyant sur des Blockchains…

Le problème avec cette promesse, c’est qu’elle repose sur des éléments très instables (les crypto-monnaies comme le Bitcoin) et très perfectibles (comme les blockchains justement !). Pas tout à fait le meilleur candidat possible pour faire vraiment mieux et plus équitable que le Web 2.0. L’argument principal des promoteurs du Web3 est qu’il sera décentralisé et, ainsi, échappera au contrôle des acteurs dominants… En fait, cet argument cache simplement leurs volontés de devenir les nouveaux acteurs dominants et de profiter de ce pouvoir pour se comporter en terrains conquis (je ne suis pas le seul à le dire, lisez donc cet article https://www.lemondeinformatique.fr/actualites/lire-web3-ou-la-chimere-de-l-internet-du-futur-85285). 

Tout cela m’évoque furieusement les années 90 où Oracle dénonçait les pratiques abusives d’IBM et incitait les clients à quitter big blue pour se réfugier au sein du “gentil rouge”… Aujourd’hui, je doute que les clients qui subissent les pratiques commerciales du “gentil rouge” puissent vraiment faire la différence avec le temps où ils subissaient le joug d’IBM !

Tous ces acteurs ont un agenda (tous !) : les gros veulent rester au sommet (Mark veut se réinventer avec Meta pour ne pas chuter), les petits veulent y grimper pour admirer la vue… C’est l’éternel histoire du monde, ne vous laissez pas abuser par les promesses des promoteurs du Web3. Au lieu de raconter leurs histoires, je préférerais les voir s’occuper des performances lamentables des blockchains (et les faire consommer moins d’énergie stupidement aussi pendant qu’on y est !), pour commencer avant de nous promettre de l’appliquer à tout le Web et toute l’informatique (il faut leur reconnaître cela : ces jeunes loups du Web3 sont ambitieux) !

Pour se convaincre que la Blockchain n’est pas encore à niveau pour se généraliser, il suffit de lire cet article : https://www.usenix.org/publications/loginonline/web3-fraud 

Bref, on l’aura compris, le Web3 n’est pas l’avenir de l’informatique ni du Web mais une combine de plus pour recycler encore plus de crypto-monnaies bidons.

Un dernier mot plus personnel

C’est ma dernière chronique pour Redsen. Après une cinquantaine de textes sur différents sujets, il est désormais temps de refermer ce chapitre. Commencé en février 2018, cela fait donc quatre ans que nous balayons ensemble l’évolution du marché et des techniques informatiques.

Nous avons constaté la généralisation du cloud et nous en sommes désormais à disserter sur des tendances moins solides comme le Web3… signe des temps présents peut-être.

J’ai été heureux de pouvoir vous proposer ces analyses et il est temps pour moi de continuer à observer l’informatique mais d’une manière différente. Merci pour votre attention.