Ingénierie logicielle pour la supply chain - Cours 4.6

00:02 Introduction
01:43 Mécanisation
07:34 Au-delà du paradoxe
12:14 L’histoire jusqu’à présent
14:32 Les sous-modules d’aujourd’hui
16:24 Exigences (courant dominant 1/5)
20:12 Conception (courant dominant 2/5)
25:37 Construction (courant dominant 3/5)
30:29 Test (courant dominant 4/5)
34:09 Maintenance (courant dominant 5/5)
41:12 Identité (tranchées 1/8)
46:35 Résumé (tranchées 2/8)
51:43 Pratiques (tranchées 3/8)
56:47 Bastions (tranchées 4/8)
01:02:00 Code writers (tranchées 5/8)
01:06:23 Tolérance à la douleur (tranchées 6/8)
01:14:55 Productivité (tranchées 7/8)
01:21:37 L’inconnu (tranchées 8/8)
01:27:00 Conclusion
01:29:55 4.6 Ingénierie logicielle pour la supply chain - Questions ?

Description

Apprivoiser la complexité et le chaos est la pierre angulaire de l’ingénierie logicielle. Étant donné que les supply chains sont à la fois complexes et chaotiques, il n’est pas surprenant que la plupart des problèmes de logiciel d’entreprise auxquels sont confrontées les supply chains se résument à une mauvaise ingénierie logicielle. Les recettes numériques utilisées pour optimiser les supply chains sont des logiciels et, par conséquent, soumises au même problème. Ces problèmes s’intensifient avec la sophistication des recettes numériques elles-mêmes. L’ingénierie logicielle appropriée est pour les supply chains ce que l’asepsie est pour les hôpitaux : à elle seule, elle ne fait rien - comme le traitement des patients - mais sans elle, tout s’effondre.

Transcription complète

Bienvenue dans cette série de conférences sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter “L’ingénierie logicielle pour la supply chain”. Le logiciel est le fondement d’une pratique moderne de la gestion de la supply chain, pourtant la plupart des manuels de supply chain sous-estiment considérablement le rôle du logiciel dans la supply chain. Le logiciel pour la supply chain n’est pas qu’une simple exigence comme l’accès aux moyens de transport ; c’est bien plus que cela. Du point de vue des praticiens de la supply chain, la plupart du travail est motivé par le logiciel, par les bugs logiciels ou les limitations du logiciel, et par les préoccupations liées au logiciel.

L’ingénierie logicielle est la discipline qui a pour ambition d’aider les gens à créer de meilleurs logiciels, à en tirer davantage, à créer ce logiciel plus rapidement et à dépenser moins pour en obtenir plus. L’objectif de cette conférence est de comprendre en quoi consiste l’ingénierie logicielle et de comprendre son importance primordiale pour la supply chain. L’objectif de cette conférence est également de comprendre ce que vous, en tant que praticien de la supply chain, pouvez faire pour éviter de paralyser votre supply chain, que ce soit par des actions ou des inactions qui, malheureusement, ont eu pour effet d’entraver vos projets logiciels.

Le XXe siècle a été le siècle de la mécanisation de la main-d’œuvre. Les grandes entreprises et les grandes supply chains, telles que nous les connaissons, ont émergé au XXe siècle, et les progrès réalisés grâce à la mécanisation de la main-d’œuvre ont été incroyables. Au cours du dernier siècle, pour presque toutes les tâches intensives en main-d’œuvre qui sont pertinentes pour la supply chain, telles que la production ou la distribution, la productivité a été multipliée par cent.

Au contraire, je crois que le XXIe siècle est et sera le siècle de la mécanisation du travail intellectuel, et cette transition est très difficile à appréhender. L’intuition qui s’applique lorsque nous passons de la mécanisation de la main-d’œuvre physique ne se traduit pas du tout par l’intuition qui s’applique lorsque nous passons à la mécanisation du travail intellectuel. Je ne dis pas que la transition est moins dramatique, mais la réalité est qu’à ce stade, la transition vers l’élimination de la main-d’œuvre qui s’occupait de tâches très intensives en main-d’œuvre est déjà derrière nous.

En 2020 en France, il y avait 27 millions de personnes occupant des emplois de cols blancs - essentiellement des employés de bureau - tandis qu’il ne restait plus d’un million de personnes qui étaient ouvriers d’usine. Le ratio est de 27 pour 1. Lorsque nous commençons à examiner ce que la mécanisation du travail intellectuel implique, c’est très surprenant et cela est également très lié à un paradoxe connu sous le nom de paradoxe de Moravec.

Hans Moravec, un informaticien, a remarqué en 1980 que concernant l’informatique, les tâches qui semblaient les plus difficiles pour l’esprit humain, comme devenir un grand maître d’échecs, étaient en réalité les types de tâches les plus faciles à aborder avec des ordinateurs. Au contraire, si nous regardons les tâches qui semblent extrêmement faciles pour les humains, comme se tenir debout sur deux jambes, ces tâches s’avèrent incroyablement difficiles pour les ordinateurs. C’est l’essence du paradoxe de Moravec : notre intuition sur ce qui est difficile à réaliser en termes de tâches intellectuelles avec des ordinateurs est très trompeuse.

Une chose qui complique encore davantage le problème est que soudain, lorsque nous parlons de l’automatisation des employés de bureau, cela est fait par les employés de bureau eux-mêmes. Ce n’était pas le cas des ouvriers d’usine ; ce n’étaient pas eux qui décidaient que l’usine serait davantage mécanisée et que leurs emplois seraient supprimés. Pourtant, c’est ce qui se passe avec les emplois de cols blancs. Ainsi, nous avons un défi où non seulement le processus de mécanisation est profondément contre-intuitif en raison du paradoxe de Moravec, mais la gestion des personnes chargées de mettre en œuvre cette mécanisation, à savoir les ingénieurs logiciels, est elle-même très contre-intuitive. C’est probablement l’un des plus grands défis pour la supply chain : la gestion des personnes qui seront chargées, d’une manière ou d’une autre, de faire face à cette mécanisation.

Ici, je ne peux m’empêcher de remarquer que de nombreuses supply chains et entreprises associées sont encore fermement ancrées dans une mentalité du XXe siècle, où vous abordez le monde de l’entreprise comme si vous aviez des personnes de cols blancs effectuant le travail intellectuel, puis elles trouvent la solution ou le plan, qui est ensuite remis aux ouvriers d’usine pour l’exécution. Cependant, avec un ratio de 27 personnes pour une en ce qui concerne les emplois de bureau par rapport aux emplois d’usine en France, et probablement des statistiques similaires dans la plupart des pays développés, ce n’est pas ainsi que cela se passe maintenant. Il s’agit littéralement d’automatiser votre propre travail, et cela signifie que dans ce monde du XXIe siècle, les meilleurs employés de cols blancs sont ceux qui parviennent constamment à s’automatiser, à se rendre obsolètes, puis à passer à autre chose. Cela représente un défi très difficile pour de nombreuses entreprises qui sont encore très ancrées dans la mentalité du XXe siècle.

Les opinions divergent largement sur la notion même de génie logiciel. Une des critiques les plus virulentes vient d’Edsger Dijkstra, l’un des pères fondateurs de l’informatique. Selon lui, le génie logiciel n’est même pas possible en tant que discipline ou domaine de recherche, et il affirme que cela se résume à une sorte de recette de “comment programmer si vous ne pouvez pas”. La critique de Dijkstra, qui est très intéressante, est que le génie logiciel se transforme en une sorte de fiction d’auto-assistance qui ne peut pas réussir. En effet, si nous proposons que l’objectif du génie logiciel est d’assurer le succès de la création de logiciels utiles et supérieurs, alors le génie logiciel est voué à l’échec. Le succès en informatique est incroyablement difficile ; c’est aussi difficile que le succès en science. Cela demande une étincelle de génie, beaucoup de chance, et il n’y a pas de recette pour cela. De plus, chaque succès tend à consommer l’opportunité même qui a permis d’atteindre ce succès, et donc tout devient non reproductible.

Cependant, je ne suis pas d’accord avec la vision selon laquelle le génie logiciel est condamné. Je pense que le principal problème réside dans la définition de l’ambition du génie logiciel. Si nous décidons que l’ambition du génie logiciel est le succès dans la création de logiciels, alors il est effectivement condamné. Cependant, si nous décidons d’aborder le génie logiciel comme une sous-branche étroite de la psychologie expérimentale, je pense que nous pouvons recueillir, par le biais de cet angle, des idées précieuses et exploitables, et c’est la perspective que j’adopterai aujourd’hui dans cette conférence. Ainsi, le génie logiciel concerne les ingénieurs logiciels eux-mêmes et leurs interactions. Se concentrer sur les ingénieurs logiciels est un bon point de départ car la nature humaine est stable dans le temps, contrairement à la technologie logicielle qui change constamment. La nature des personnes qui luttent avec cette technologie ne l’est pas ; la nature humaine est restée très stable pendant très longtemps.

Si nous regardons d’autres domaines, tels que la science, nous pouvons voir qu’approcher un domaine à travers l’inspection de ce que font ses praticiens peut être très fructueux. Par exemple, il est maintenant largement établi en science qu’un conflit d’intérêts conduit à de mauvaises pratiques scientifiques et à une corruption des connaissances. Ce point a été abordé précédemment dans la conférence intitulée “Recherche de marché adversaire pour les logiciels d’entreprise”. Dans cette perspective, nous voyons qu’il est possible de recueillir des idées d’applicabilité et de pertinence étendues si nous nous concentrons sur les praticiens eux-mêmes. Ainsi, le génie logiciel concerne les personnes qui travaillent avec la technologie logicielle, leurs luttes et leurs processus, et pas tant la technologie elle-même.

Aujourd’hui est la sixième conférence des quatre chapitres. Ce chapitre est consacré aux sciences auxiliaires de la supply chain. Ces sciences auxiliaires représentent des éléments que je considère comme d’une importance fondamentale pour une pratique moderne de la supply chain, mais ils ne sont pas strictement des éléments de la supply chain. Ce sont plutôt des éléments de soutien pour votre pratique de la supply chain.

Jusqu’à présent, dans ce quatrième chapitre, nous avons commencé par la physique de l’informatique, en traitant des ordinateurs modernes, puis nous avons progressé à travers une échelle d’abstractions. Nous sommes passés des ordinateurs aux algorithmes, qui représentent les plus petites parties d’intérêt dans les logiciels. Ensuite, nous sommes passés à l’optimisation mathématique, qui est d’intérêt pour la supply chain mais aussi pour de nombreuses autres entreprises logicielles pertinentes, telles que l’apprentissage automatique. Nous avons vu que l’optimisation mathématique est directement intéressante pour la supply chain, mais elle est également directement intéressante pour l’apprentissage automatique, qui, à son tour, est également d’intérêt pour la supply chain.

En ce qui concerne l’optimisation mathématique et l’apprentissage automatique, la plupart des concepts et paradigmes intéressants de nos jours sont de nature programmatique. Il ne s’agit pas seulement d’algorithmes simples ; c’est quelque chose d’incroyablement expressif et qui doit être abordé à travers le prisme des langages de programmation. C’est pourquoi la dernière conférence portait sur les langages et les compilateurs.

Aujourd’hui, nous continuons à monter cette échelle d’abstraction, et nous nous concentrons sur les personnes plutôt que sur ce qu’elles font. Nous allons nous concentrer sur les ingénieurs logiciels eux-mêmes, et c’est tout l’intérêt de cette analyse de l’ingénierie logicielle.

Aujourd’hui, je vais présenter spécifiquement deux points de vue sur l’ingénierie logicielle. Tout d’abord, je présenterai le point de vue dominant, qui, je pense, domine le domaine. Malheureusement, ce point de vue dominant a suscité des critiques, comme mentionné précédemment, avec des personnes présentant des approches d’auto-assistance que certaines, y compris moi-même, ont des raisons de contester car elles ne présentent pas une ambition réaliste pour la discipline de l’ingénierie logicielle. Néanmoins, je passerai en revue ce point de vue dominant, ne serait-ce que parce que certaines idées erronées sont encore incroyablement populaires. Il est primordial de connaître ces concepts erronés, ne serait-ce que pour éliminer les personnes incompétentes qui pourraient mettre en danger votre supply chain par leur incompétence.

Ensuite, je passerai à une vision du terrain, qui est une collection d’éléments enracinés dans mon expérience personnelle en tant que PDG d’une entreprise de logiciels qui opère précisément dans le domaine des logiciels de supply chain d’entreprise. Comme nous le verrons, les idées sont très axées sur les personnes et pas vraiment sur la technologie elle-même.

Le point de vue dominant de l’ingénierie logicielle affirme qu’une initiative logicielle commence par la collecte des exigences pour le logiciel concerné. La plupart des initiatives logicielles dans les grandes entreprises adoptent cette perspective à travers un processus qui commence généralement par une demande de proposition (RFP), une demande de devis (RFQ) ou une demande d’information (RFI). Cette approche est héritée des pratiques du XXe siècle qui ont été très réussies dans le domaine de l’ingénierie mécanique et des travaux de construction. Cependant, je pense que, en ce qui concerne les logiciels, ces approches de collecte des exigences sont profondément erronées.

En informatique, vous ne savez pas ce que vous voulez ; vous ne le savez tout simplement pas. Savoir ce que vous voulez est invariablement la partie la plus difficile du logiciel. Par exemple, si nous considérons un problème simple comme le réapprovisionnement des stocks, l’énoncé du problème est incroyablement simple : à n’importe quel moment, je veux connaître la quantité que je devrais réapprovisionner ou commander pour chaque SKU. Le problème lui-même est simple, mais définir ce qu’est une bonne quantité devient diaboliquement complexe et difficile. En règle générale, clarifier les exigences est beaucoup plus difficile que d’écrire le logiciel lui-même.

C’est seulement en confrontant votre intuition avec les retours du monde réel que vous pouvez laisser émerger les exigences. Les exigences ne tombent pas du ciel ; elles ne peuvent être obtenues que par le biais d’un processus assez expérimental, et vous devez avoir cette interaction avec le monde réel. Cependant, la seule façon d’avoir cette interaction est d’avoir le produit logiciel, car la collecte des exigences est fondamentalement un processus très empirique et émergent. Le problème est que lorsque vous avez terminé avec les exigences, avoir les exigences devient inutile, car si vous avez les exigences, cela signifie que vous avez déjà le produit correspondant qui met en œuvre ces exigences. Donc, lorsque vous avez accès aux exigences appropriées, vous avez déjà le produit en production, opérationnel, et le fait d’avoir ces exigences est quelque peu sans importance.

Ainsi, le point est que commencer le processus à travers le prisme des exigences est, je crois, une folie. Les exigences devraient probablement venir en dernier en tant que documentation de dernière étape, où vous documentez toutes les raisons principales qui vous ont amené à implémenter le produit de la manière dont vous l’avez fait, et non l’inverse.

Une fois que les exigences sont établies, l’approche classique stipule qu’il faut passer à la phase de conception. Je suis d’accord pour dire qu’à un moment donné, une certaine conception peut se produire. Cependant, le genre de réflexion qui intervient dans cette phase de conception est souvent erroné. Le problème se résume à maîtriser le coût du changement. La perspective classique non logicielle sur le coût du changement est que le coût augmente de manière exponentielle avec le temps. Par exemple, si vous modifiez la conception d’une voiture très tôt, lorsque vous ne travaillez qu’avec un plan, le coût du changement est minime. En revanche, si vous attendez que des millions de ces voitures soient sur les routes, le coût du changement est extrêmement élevé car cela implique un rappel, ce qui peut être incroyablement coûteux.

Cependant, contrairement au domaine physique, dans le domaine logiciel, le coût du changement n’augmente pas naturellement de manière exponentielle. L’augmentation du coût ne peut pas être entièrement atténuée ; cependant, dans une large mesure, l’augmentation du coût peut être gérée. En effet, le coût du changement augmente avec le temps, principalement parce que les bases de code ont tendance à croître avec le temps. Je n’ai jamais vu une base de code d’un logiciel d’entreprise diminuer de manière significative d’une année à l’autre ; elles ont tendance à continuer à croître. Néanmoins, il est possible de gérer le coût du changement dans une certaine mesure.

De nos jours, cet aspect est de plus en plus reconnu, même dans les cercles logiciels. Au fait, c’est l’essence de la méthodologie Agile. Vous avez peut-être vu ces termes circuler lorsque les gens disent : “Oh, nous avons cette méthodologie Agile pour les logiciels.” L’un des plus grands objectifs de la méthodologie Agile est de maîtriser le coût du changement. Je ne vais pas entrer dans les détails aujourd’hui sur la méthodologie Agile, mais je pense que cette approche est légèrement erronée en ce qui concerne la manière exacte de maîtriser ce coût du changement.

J’ai observé que le coût du changement provient principalement des décisions prises concernant le logiciel et, plus précisément, du fait qu’il est très difficile de résister à l’envie de prendre des décisions. Imaginez que vous regardez un futur produit logiciel potentiel et qu’il y a beaucoup de décisions à prendre. La première tentative serait de prendre ces décisions simplement pour clarifier ce que vous avez devant vous. Au contraire, une très bonne phase de conception, plutôt qu’une bonne conception, consiste à reporter toutes les décisions qui ne sont pas absolument nécessaires, là où le produit n’exige pas que ces décisions soient prises maintenant. En effet, si vous ne prenez pas la décision, tant que la décision n’est pas prise et que vous n’avez pas établi que vous devez adopter cette approche de conception spécifique ou cette approche technologique spécifique, elle flotte encore dans l’air, prête à être modifiée car rien n’a encore été décidé.

L’un des aspects pour maîtriser le coût du changement est d’apprendre à reporter toutes les décisions dans la mesure du possible. D’un point de vue de la supply chain, cela semble très étrange car cela signifie que pour toutes les personnes de l’équipe logicielle et toutes les personnes observant le produit et l’équipe logicielle, il semble qu’elles soient maintenues dans l’ignorance. C’est même pire que ça car elles sont maintenues dans l’ignorance intentionnellement, ce qui est très déconcertant. Pourtant, c’est précisément ce qui doit se produire et cela doit être fait intentionnellement. C’est pourquoi c’est déconcertant, pour le moins que l’on puisse dire.

Maintenant, si les décisions de conception prématurées sont enracinées dans le besoin parfois erroné de contrôle, les problèmes associés à ce besoin de contrôle ne s’arrêtent pas là. Une fois la phase de conception terminée, la vision dominante de l’ingénierie logicielle indique que nous devrions procéder à la construction du logiciel, également appelée phase de mise en œuvre. La façon dont cela est généralement fait est de présenter une sorte de projection en cascade, également appelée diagrammes de Gantt. C’est ce que vous pouvez voir à l’écran. Je pense que cette approche, les diagrammes de Gantt et les cascades, est incroyablement toxique et que la toxicité de cette approche ne doit pas être sous-estimée en ce qui concerne les logiciels. Aborder le problème de cette manière revient littéralement à condamner votre supply chain à l’échec, du moins en ce qui concerne ses initiatives logicielles.

Une bien meilleure façon de comprendre le problème et d’aborder la construction du logiciel est de le considérer comme un processus d’apprentissage. La construction du logiciel consiste à apprendre tout ce qu’il faut pour obtenir un bon produit. Il s’agit d’un processus d’apprentissage et toutes ces parties apprises sont un sous-produit de laisser le monde interagir avec le logiciel qui émerge du processus de construction. Le problème clé avec une prédiction en cascade est que vous projetez ce que vous êtes sur le point de découvrir. Cela n’est tout simplement pas possible par définition. Ce que vous êtes sur le point de découvrir était inconnu jusqu’à ce que vous découvriez ces éléments. Vous ne pouvez pas projeter vos découvertes. Vous pouvez les attendre, mais vous ne pouvez pas planifier les détails de ce que vous êtes sur le point de découvrir. Vous pouvez avoir des intuitions, mais c’est tout ce que vous pouvez obtenir. L’idée que vous pouvez transformer ces intuitions vagues en une prédiction en cascade précise est, encore une fois, une folie totale.

Au fait, ce petit paradoxe apparent concernant la construction de logiciels en tant que processus d’apprentissage explique également pourquoi parfois la réplication d’un logiciel peut être soit incroyablement facile, soit incroyablement difficile. Si une équipe tente de reproduire un produit logiciel qui est déjà sur le marché, et que cette équipe a accès à la compréhension ou aux leçons qui ont conduit à la production du logiciel qu’elle essaie de copier, alors reproduire le produit logiciel - le réimplémenter ou le recoder - peut être fait avec seulement une infime fraction du temps et du budget qui ont été nécessaires pour créer le logiciel en premier lieu. Au contraire, si l’équipe n’a pas accès à ces connaissances de haut niveau, et par exemple, la seule chose à laquelle elle a accès est le code source, l’équipe se retrouvera très souvent avec un produit de très basse qualité car essentiellement, toutes les parties apprises ou les connaissances ont été perdues. Vous avez simplement reproduit l’apparence superficielle du produit.

Du point de vue de la supply chain, le plus grand défi ici est de renoncer volontairement et de maîtriser votre besoin de contrôle. Le processus en cascade est l’expression d’une entreprise qui veut contrôler le processus. Par exemple, si je dis : “mettons ce projet sous contrôle”, cela serait perçu comme quelque chose de très raisonnable. Pourquoi feriez-vous le contraire ? Pourquoi diriez-vous, par exemple, “laissons ce projet complètement hors de contrôle” ? Mais la réalité est que ce degré de contrôle est une illusion totale en ce qui concerne les logiciels, et cela nuit complètement à votre capacité de livrer un produit de haute qualité à la fin. Maîtriser votre désir de contrôle est, du point de vue de la supply chain, probablement le plus grand défi lorsqu’il s’agit de la construction de logiciels.

Depuis l’émergence des programmes informatiques, ils ont été truffés de bugs et de défauts. Pour résoudre ces problèmes évidents, l’opinion générale est que des tests doivent être effectués. Les tests prennent de nombreuses formes. En ce qui concerne le besoin de tests, je suis d’accord, bien que cela soit très vague à ce stade. Certains outils insistent sur le fait que les tests doivent être effectués après la construction, certains insistent sur le fait que les tests doivent être effectués pendant la construction, et d’autres précisent que les tests doivent être effectués avant la construction. Certaines approches indiquent que les tests doivent être effectués avant, pendant et après la construction du logiciel.

Mon point de vue général sur le problème est que vous devriez faire tout ce qu’il faut pour rendre la boucle de rétroaction aussi courte que possible. Nous avons discuté de ce point lors de la conférence précédente : rendre la boucle de rétroaction aussi courte que possible est d’une importance capitale pour obtenir quelque chose qui fonctionne dans le monde réel. Ainsi, je recommanderais généralement de prêter attention à savoir si ce que vous faites en termes de tests resserre réellement cette boucle de rétroaction ou non. Par exemple, pour la plupart des situations, je ne recommanderais pas naturellement le développement piloté par les tests (une méthodologie qui dit que les tests passent en premier), simplement parce que pour la plupart des situations, les tests en premier ne feront que retarder le moment où vous obtenez des retours sur votre logiciel de la part du monde en général.

Cependant, ma plus grande préoccupation concernant les tests est une limitation non mentionnée, quelque chose qui semble être généralement négligé. Les tests ne peuvent finalement évaluer que la conformité aux règles que vous avez établies vous-même. Le problème est qu’en informatique, il n’y a pas de contraintes strictes. Il n’y a pas de moyen chimique d’approcher l’adéquation de votre produit par rapport au problème que vous essayez de résoudre. C’est très différent du domaine physique. Par exemple, en génie mécanique, il existe un critère canonique : la tolérance dimensionnelle d’une pièce. Quoi que vous fassiez en termes de génie mécanique, la tolérance dimensionnelle sera d’une importance primordiale. C’est un candidat évident et naturel. Cependant, il n’y a pas de candidats évidents et naturels en informatique.

Le problème ici devient celui de l’adéquation. Si nous voulons prendre un exemple de chaîne d’approvisionnement, comme les stocks de sécurité, il est tout à fait simple de concevoir une suite de tests automatisés pour valider les calculs des stocks de sécurité. Il est très simple de mettre en œuvre ce type de logique de test. Cependant, cela ne peut pas vous dire que les stocks de sécurité sont une mauvaise idée en premier lieu. Vous ne testez que ce que vous connaissez.

Lorsque nous traitons avec une machine physique, nous nous attendons à l’usure, et donc nous nous attendons à une certaine forme de maintenance pour maintenir la machine en état de fonctionnement. Cependant, pourquoi un logiciel aurait-il besoin d’un quelconque type de maintenance pour continuer à fonctionner ? Certes, nous devons remplacer les ordinateurs lorsqu’ils tombent en panne de temps en temps. Cependant, cet aspect est très marginal, et dans les logiciels d’entreprise, les pannes physiques des machines ne représentent même pas 10% des coûts de maintenance réels. Cela existe, mais l’impact de ce type de maintenance est extrêmement mince.

Pourtant, la maintenance des logiciels d’entreprise est d’une importance primordiale. Les coûts de maintenance sont énormes. Pour de nombreux éditeurs de logiciels d’entreprise, la maintenance représente littéralement 80% ou plus du coût d’ingénierie. Il s’avère que les facteurs qui génèrent ce besoin de maintenance ont très peu à voir avec la physique. Le premier facteur est la volonté de payer des clients eux-mêmes. Si un fournisseur peut s’en tirer avec des frais de maintenance annuels de 20% par rapport à ce qui a été payé pour la configuration du logiciel au cours de la première année, alors le fournisseur de logiciel facturera cela. Essentiellement, du point de vue des coûts, le coût de la maintenance est déterminé par la volonté de payer des clients d’entreprise.

Le deuxième facteur est le type de maintenance qui doit être effectué simplement pour maintenir le logiciel en fonctionnement. En effet, pour chaque jour qui passe, l’environnement entourant le produit d’intérêt s’éloigne du produit. Le système d’exploitation continue d’évoluer, le système de base de données continue d’évoluer, et il en va de même pour toutes les bibliothèques tierces utilisées par le logiciel. Aucun produit logiciel n’est une île. Chaque produit logiciel dépend d’une myriade d’autres produits logiciels, et ces autres produits évoluent de leur côté. Les personnes qui développent ces produits logiciels continuent de travailler dessus, et en travaillant sur ces produits, elles les modifient. Ainsi, il arrive un moment où le produit que vous avez cesse simplement de fonctionner parce qu’il y a une incompatibilité. Vous n’avez rien fait d’autre que de ne pas suivre le reste du marché. Le deuxième facteur est toute la maintenance qui doit être effectuée simplement pour maintenir le logiciel en marche et le rendre compatible avec le reste du marché.

Le troisième facteur est la quantité de travail nécessaire pour maintenir le produit utile. En effet, le logiciel a été conçu et développé à un certain moment, et chaque jour qui passe, le monde s’éloigne de ce qui était prévu au moment où le produit a été conçu. Ainsi, même si rien ne se casse vraiment en termes de compatibilité matérielle, il s’avère que lorsque le monde change, inévitablement, l’utilité du produit diminue car le monde s’éloigne simplement des attentes qui étaient intégrées dans le produit. Si vous voulez que le logiciel reste utile, vous devez constamment le maintenir.

Du point de vue de la supply chain, la maintenance est un grand défi, et nous avons abordé cet aspect dans la conférence précédente, qui portait sur la livraison orientée produit pour la supply chain. Le coût de la maintenance a un impact significatif sur les avantages capitalistes que vous pouvez tirer de votre projet logiciel. Idéalement, vous voulez que votre projet logiciel ait un retour sur investissement très élevé, mais pour cela, vous devez vous assurer de ne pas vous retrouver avec des coûts de maintenance massifs. Ces coûts annuleront complètement le profit et le rendement capitalistes que vous pouvez obtenir de votre investissement logiciel.

Le plus grand défi ici, encore une fois du point de vue de la supply chain, est que le moyen le plus simple de minimiser les coûts de maintenance est de se concentrer sur ce qui ne change pas. Comme je l’ai mentionné précédemment, la plupart des coûts sont liés aux choses qui se trouvent être en train de changer, que ce soit dans l’écosystème logiciel ou dans le monde en général. Cependant, si vous vous concentrez sur les choses qui ne changent pas, alors ce que vous obtenez, c’est essentiellement la majeure partie de votre logiciel qui ne se détériorera que lentement car, précisément, la plupart des problèmes auxquels votre logiciel s’attaque sont des choses qui ne changent pas.

Le problème est que se concentrer sur ce qui ne change pas est plus facile à dire qu’à faire, car vous avez une force très humaine qui s’oppose à cette intention : la peur de passer à côté de quelque chose. Lorsque vous regardez la presse, les médias, vos collègues, etc., il y aura un flux constant de nouveautés, de mots à la mode, et chaque mot à la mode a cette envie, due à la peur de passer à côté, de simplement faire la chose et de ne pas être laissé de côté. Par exemple, tous ces mots à la mode seraient l’IA, la blockchain, l’IoT, et toutes ces choses qui sont très présentes. Je pense que dans la supply chain, ces mots à la mode sont vraiment une distraction et ils contribuent significativement aux problèmes de maintenance car ils détournent l’attention de ce qui ne change pas. Au contraire, lorsque vous commencez à vous intéresser à ces mots à la mode, vous surfez sur une vague, et vous surfez exactement sur le genre de choses qui sont très susceptibles de changer avec le temps, ce qui fait augmenter vos coûts de maintenance au fil du temps.

Maintenant que nous avons terminé avec la vision traditionnelle de l’ingénierie logicielle, plongeons dans une série de pépites personnelles qui devraient être utiles pour mener des initiatives logicielles tout en gardant à l’esprit la supply chain. L’un des problèmes les plus fréquents lorsqu’il s’agit de personnes travaillant dans le domaine du logiciel est une méconnaissance de leur propre identité, et je vole cette idée à un entrepreneur nommé Paul Graham. Un ingénieur dira par exemple : “Je suis un ingénieur Python”. Bien que cela ne soit pas aussi extrême, il est très fréquent que les ingénieurs logiciels perçoivent leur propre identité à travers une courte série de technologies qu’ils maîtrisent, qui constituent leur ensemble de compétences. Cette confusion entre leur identité et leur ensemble de compétences actuel tend à être renforcée par les pratiques de recrutement qui prévalent dans le domaine de l’informatique et du logiciel en général. Du point de vue du recrutement, de nombreuses entreprises indiquent dans leurs offres d’emploi : “J’ai besoin d’un programmeur Python”. Ainsi, avoir la bonne identité n’est pas seulement une question de perception ; il y a des récompenses financières attachées au fait d’avoir la bonne identité, la bonne étiquette, la bonne étiquette que vous pouvez vous attribuer, ce qui vous rend plus attractif sur le marché.

Cependant, cette perception axée sur l’identité, où les technologies deviennent attachées à soi en tant qu’ingénieur logiciel, entraîne de nombreux problèmes qui affectent pratiquement tous les projets logiciels, et en particulier les projets logiciels de la supply chain. Lorsque vous interagissez avec une personne, généralement un ingénieur logiciel, dont l’identité est fortement attachée à la technologie en place dans votre entreprise, le problème est que chaque critique de la technologie a tendance à être perçue comme une attaque personnelle. Si vous dites que je suis un programmeur Python et que vous critiquez mon logiciel, je le prends personnellement. Le problème est que dès que les gens considèrent les critiques de la technologie comme des critiques personnelles, il devient très difficile de raisonner sur ces problèmes. Ces ingénieurs logiciels auront malheureusement tendance à rejeter tous les commentaires, simplement parce qu’ils les voient en partie comme des critiques personnelles.

À l’inverse, si l’entreprise utilise une technologie qui n’est pas perçue comme l’identité principale par l’ingénieur logiciel, par exemple, votre entreprise a mis en place des systèmes en Java et vous avez un ingénieur logiciel qui dit : “Je suis un programmeur Python”, alors tous les problèmes seront perçus à travers le prisme de cette technologie comme étant inférieure. Encore une fois, c’est un autre problème où les critiques et les commentaires seront rejetés avec l’attitude de “ce n’est pas mon problème ; c’est simplement à cause de cette technologie très médiocre qui a été utilisée ici et maintenant dans cette entreprise”. Dans les deux situations, que l’ingénieur logiciel ait une identité attachée à la technologie que vous utilisez ou une identité attachée à une technologie que vous n’utilisez pas, cela crée toute une série de problèmes et les commentaires sont rejetés au lieu d’être utilisés pour améliorer la technologie.

Maintenant, d’un point de vue de la supply chain, nous devons garder à l’esprit que l’environnement de la supply chain est incroyablement chaotique et que donc des problèmes se produiront tout le temps. C’est précisément en raison de ce chaos ambiant qu’il est très important d’avoir des équipes d’ingénieurs logiciels capables de regarder droit dans les yeux ces problèmes et d’y remédier, et non pas de rejeter les commentaires lorsqu’ils surviennent. Il est crucial de constituer des équipes qui n’encouragent pas le drame en plus du chaos de la supply chain en raison de leur perception de leur identité.

Cette idée s’applique également aux ingénieurs logiciels, qui choisissent souvent des technologies qui correspondent à leur identité ou à l’identité qu’ils souhaitent acquérir. Ils choisissent une technologie pour acquérir des compétences, afin de pouvoir ajouter un autre mot-clé à leur CV. Cependant, cette approche conduit à choisir des technologies pour des raisons sans rapport avec la résolution des problèmes auxquels l’entreprise est confrontée. Il s’agit de la mauvaise perspective pour décider si une technologie est pertinente ou adéquate pour résoudre les problèmes spécifiques auxquels l’organisation est confrontée.

Construire un CV peut être un puissant moteur de motivation pour les ingénieurs logiciels, car il existe des avantages financiers réels associés à la présence d’une liste de mots-clés. Les meilleures entreprises de logiciels regardent souvent de haut les CV avec une longue liste de mots-clés. En tant que PDG de Lokad, si je vois un CV avec une demi-page de mots-clés, il est directement rejeté. Cependant, de nombreuses entreprises, en particulier médiocres, recherchent activement des personnes ayant de nombreux mots-clés, pensant que ces individus seront incroyablement polyvalents et agiles au sein de l’organisation. D’après mon expérience, c’est souvent le contraire.

Poursuivant le sujet de l’identité et de la construction du CV, il est essentiel de prêter attention au fait que les architectes logiciels ne doivent pas être trop attachés à une technologie particulière. Il est déjà difficile d’embaucher des ingénieurs logiciels, il faut donc parfois faire des compromis. Cependant, en ce qui concerne les architectes logiciels, faire des compromis en sélectionnant des personnes ayant un attachement émotionnel à une certaine technologie peut être désastreux. Ces individus auront un impact à grande échelle sur votre entreprise.

Ce problème de biais de construction de CV ne se limite pas aux ingénieurs logiciels ou aux professionnels du logiciel. Il se produit également parmi le personnel informatique. Par exemple, j’ai rencontré plusieurs directeurs informatiques de grandes entreprises qui voulaient passer à SAP alors que leur ERP existant était parfaitement fonctionnel. Les coûts massifs associés à la transition vers SAP ne seraient jamais compensés par les avantages attendus d’un ERP plus moderne. Dans ces cas, un comportement irrationnel était en jeu, où l’intérêt personnel du directeur informatique de déployer SAP sur son CV l’emportait sur l’intérêt de l’entreprise elle-même.

Du point de vue de la supply chain, il est essentiel de prêter attention à ces conflits d’intérêts. Il ne faut pas beaucoup de compétences ou de compétence en logiciel pour détecter les conflits d’intérêts. Dans d’autres domaines, tels que les sciences médicales, même les médecins peuvent prescrire les mauvais médicaments en raison de conflits d’intérêts, même lorsque des vies sont en jeu. Cela démontre que les conflits d’intérêts sont incroyablement toxiques. Imaginez simplement comment ces problèmes se déroulent dans la gestion de la supply chain, où il n’y a pas de vies en jeu et où la principale préoccupation est l’argent. Il y a encore moins de réticence à laisser les conflits d’intérêts se dérouler dans ce contexte.

Contrairement au monde physique, le domaine du logiciel offre très peu de contraintes sur la manière de procéder aux initiatives logicielles et d’aborder le travail. La nature humaine n’aime pas le vide, et les gens peuvent être perturbés par un manque de structure. Par conséquent, de nombreuses pratiques ont vu le jour au fil des ans et continuent d’émerger. Chaque pratique s’accompagne d’une notion d’orthodoxie. Quelques exemples de ces pratiques comprennent la programmation extrême, la conception pilotée par le domaine, la conception pilotée par les tests, les microservices, Scrum et la programmation agile. Il existe de nombreuses pratiques, et de nouvelles émergent chaque année.

Avec chaque pratique vient une notion d’orthodoxie. Dès que les gens commencent à suivre une pratique, ils peuvent se demander s’ils adhèrent aux principes fondamentaux. Les ingénieurs logiciels ne sont que des personnes, et les personnes aiment les rituels et les tribus. Une pratique donne un sentiment d’appartenance à une tribu avec des croyances partagées. C’est pourquoi vous trouverez également des rencontres associées à ces pratiques, répondant à un besoin très humain.

Il peut être difficile, voire déprimant, de regarder un problème, incertain de tout, et de n’avoir presque personne à qui se rapporter pour aborder la question. Ce qui est intéressant, c’est que même si une pratique peut être discutable ou légèrement irrationnelle, les avantages peuvent être réels. Faire la publicité d’une pratique à l’intérieur et à l’extérieur de votre entreprise peut stimuler le moral et aider à recruter des candidats potentiels.

Lors d’un entretien d’embauche, lorsque les gens vous demandent comment vous travaillez, il n’est pas vraiment convaincant de dire que vous improvisez et n’avez aucune règle. Il est plus efficace d’inspirer confiance en présentant une pratique comme si elle résoudra les problèmes au sein de l’entreprise. Le point clé est que, à court terme, ces pratiques ne sont pas toutes mauvaises, même si elles sont principalement irrationnelles. Générer un sentiment d’appartenance peut être bénéfique. Cependant, cela devient toxique si les pratiques sont prises trop au sérieux ou pendant trop longtemps. Une pratique peut être intéressante simplement parce qu’elle vous oblige à regarder le problème sous un angle différent. Mais une fois que vous avez regardé le problème sous un angle différent, vous devriez essayer de trouver un autre angle. Vous ne devriez pas vous attarder sur un angle pendant trop longtemps. D’un point de vue de la supply chain, cela illustre l’étrangeté radicale du domaine du logiciel.

Sur le terrain de l’usine, l’excellence signifie toujours faire exactement la même chose. Dans le monde du logiciel, c’est exactement le contraire. Si vous faites la même chose, c’est une recette pour la stagnation et l’échec à long terme.

Le logiciel est complexe, et le logiciel d’entreprise l’est encore plus. Fréquemment, plusieurs ingénieurs finissent par travailler sur une initiative donnée, ce qui conduit à une tendance naturelle à la spécialisation. Lorsqu’un ingénieur travaille sur une certaine partie de la base de code, il a naturellement tendance à attribuer la même personne lorsque de nouvelles tâches nécessitent de toucher cette même partie de la base de code. Les avantages sont réels, car cette personne est déjà familière avec le code et peut être plus productive.

Le principal problème de la spécialisation est qu’elle peut conduire à un sentiment de propriété sur des parties de la base de code, créant ainsi divers problèmes. Il existe deux catégories de problèmes liés à cette propriété : le “facteur camion” et les jeux de pouvoir. Le facteur camion fait référence au risque de perdre un employé qui possède des connaissances ou des compétences uniques. Cela peut être dû au départ de l’employé pour une autre entreprise ou à son incapacité à travailler pour une autre raison. Les jeux de pouvoir peuvent survenir si un employé réalise que sa contribution est vitale pour l’entreprise et utilise cet avantage pour demander un salaire plus élevé ou d’autres avantages.

D’après mon expérience, les ingénieurs logiciels n’ont généralement pas une forte propension à jouer des jeux de pouvoir, mais ces problèmes peuvent devenir de plus en plus fréquents dans les grandes entreprises. Il existe de nombreuses pratiques d’ingénierie logicielle qui tentent de résoudre ce problème de front, comme la programmation en binôme. Cependant, l’idée clé est que trop de bonnes choses peuvent être toxiques pour l’entreprise. Le mieux est d’être conscient de cette catégorie de problème, plutôt que de s’en tenir à une pratique particulière censée résoudre le problème. C’est parce que de telles pratiques peuvent créer d’autres problèmes, vous distraire ou limiter votre capacité à prêter attention à d’autres choses que vous n’avez pas encore vues. D’un point de vue logiciel, la leçon clé ici est que la culture est l’antidote à cette catégorie de problèmes, pas le processus.

Nous sommes confrontés à une situation où nous devons faire un compromis subtil entre les gains de productivité obtenus en spécialisant les personnes dans certaines parties du code et les risques associés au fait que ces personnes possèdent ces parties du code. Ce que vous voulez, c’est cultiver une situation où il y a toujours une certaine redondance en termes de connaissance de la base de code de toute l’équipe, de sorte que chaque ingénieur ait une certaine compétence en commun. C’est un compromis très subtil que vous devez atteindre si vous voulez maintenir un certain niveau de productivité. La seule façon de le faire réellement dans le monde réel est de créer une culture bien comprise en matière d’ingénierie logicielle. Il n’y a aucun processus qui puisse garantir que les gens seront curieux du travail de leurs collègues. Vous ne pouvez pas avoir un processus sur la curiosité ; cela doit faire partie de la culture.

Évaluer les compétences et les compétences des ingénieurs logiciels est difficile, et cette question est essentielle car bien que le logiciel soit clairement un effort d’équipe et que l’équipe soit plus que la somme de ses membres, le niveau de base des membres de l’équipe a un impact important sur les performances de l’équipe dans son ensemble.

Un aspect que j’ai observé être largement sous-estimé par les personnes extérieures à l’industrie du logiciel, et parfois aussi par les personnes de l’industrie, est l’importance des compétences en rédaction. Si vous créez un logiciel, vous vous adressez à deux publics distincts. D’un côté, vous avez le public de la machine - votre compilateur. Vous écrivez du code et votre compilateur l’acceptera ou le rejettera. C’est la partie facile. Votre compilateur est votre compagnon infatigable qui vous dira si votre code est correct ou incorrect. Le compilateur est complètement prévisible et a une patience infinie.

De l’autre côté, vous avez le public de vos collègues, qui inclura probablement vous-même dans six mois. Vous écrivez du code et finirez par l’oublier. Six mois plus tard, vous regarderez le code que vous avez écrit, en pensant qu’il a été écrit par quelqu’un d’autre car il vous semble si peu familier. Lorsque vous écrivez du code pour vos collègues, l’avantage est que contrairement aux compilateurs, vos collègues essaieront de comprendre ce que vous essayez de réaliser. Le compilateur n’essaie pas de comprendre vos intentions ; il applique mécaniquement un ensemble de règles.

Vos collègues essaieront de comprendre, mais malheureusement, ils ne sont pas comme les compilateurs. Ils n’ont pas une patience infinie et peuvent être facilement confus et égarés par votre code. C’est pourquoi, par exemple, le choix de noms mémorables, perspicaces et appropriés est d’une importance primordiale. Un bon programme ne consiste pas seulement à avoir quelque chose de correct ; même le choix des noms de variables, de fonctions et de modules revêt une importance capitale si vous voulez avoir un code qui fonctionnera bien avec vos collègues, et encore une fois, vos collègues incluent vous-même dans six mois. D’un point de vue de la supply chain, la principale leçon à retenir est que les compétences en rédaction sont d’une importance primordiale, et j’irais jusqu’à dire que les compétences en rédaction sont souvent plus importantes que les compétences techniques brutes. Les bonnes compétences en rédaction sont la compétence numéro un dont vous aurez besoin pour maîtriser la complexité présente dans votre supply chain. Maîtriser la complexité de votre paysage applicatif n’est pas un grand défi technique ; c’est un défi d’organisation des idées et des éléments, et d’avoir une histoire cohérente dans l’ensemble. Ce sont des compétences très liées à l’écriture, et nous avons abordé cet aspect dans une précédente conférence intitulée “Écriture pour la Supply Chain”.

Si la compétence en rédaction est d’une importance primordiale pour être un bon ingénieur logiciel, il existe une autre compétence qui est d’une importance primordiale pour être un ingénieur logiciel tout court : la tolérance à la douleur. Je pense que c’est la compétence numéro un en ce qui concerne ce qu’il faut pour être réellement un ingénieur logiciel, pas un excellent ingénieur, juste un ingénieur. Plus précisément, lorsque je parle de douleur, je veux dire la résistance à l’ennui et à la frustration qui accompagne le processus de développement de logiciels lorsqu’on est confronté à des systèmes incroyablement fragiles, mal conçus et truffés de pièges de toutes sortes, parfois par des personnes qui ne sont même plus là. Lorsque vous travaillez avec des logiciels, vous avez quarante ans de problèmes accumulés sous vos pieds, et vous luttez contre cela tout le temps. Cela peut être un exercice incroyablement frustrant par moments.

Juste pour vous donner une illustration, en tant qu’ingénieur logiciel, vous devrez avoir la patience de passer quatre heures à fouiller des conversations aléatoires et semi-inutiles sur un forum web qui mentionnent un code d’erreur similaire à celui auquel vous êtes confronté. Vous devrez passer des heures à traverser ce genre d’absurdités pour arriver au fond du problème, et parfois il faut des semaines pour résoudre un bogue en apparence trivial. Ainsi, la conséquence de cela est que nous avons un processus de sélection adverse très intense dans toute l’industrie du logiciel, qui sélectionne des personnes ayant une grande tolérance à la douleur. Ce processus de sélection a deux conséquences majeures.

Premièrement, les personnes qui restent ingénieurs logiciels ont tendance à être incroyablement tolérantes à la douleur. Lorsque je dis tolérantes à la douleur, je veux dire résistantes à la frustration face aux problèmes logiciels constants auxquels elles sont confrontées. Comme vous sélectionnez des personnes ayant une tolérance incroyable à la douleur, elles peuvent ne pas reconnaître quand leurs actions aggravent la situation. Elles peuvent ajouter des particularités supplémentaires aux produits logiciels, augmentant ainsi le niveau de douleur lors de l’interaction avec le logiciel pour tout le monde, y compris elles-mêmes. Cependant, si elles sont incroyablement tolérantes à la douleur, elles n’y prêtent pas attention. Ce processus de sélection adverse exclut les personnes ordinaires qui y prêteraient attention mais ne sont pas devenues ingénieurs logiciels parce qu’elles ne supportaient pas la douleur. Ce problème est particulièrement intense pour les logiciels de la chaîne d’approvisionnement car il y a de nombreux aspects qui ne sont pas très excitants. Certains aspects peuvent être nécessaires mais banals, ce qui signifie que les personnes ayant une grande tolérance à la douleur opérant dans ce domaine peuvent aggraver la situation en raison de l’abondance de tâches potentiellement ennuyeuses.

Le deuxième aspect de ce processus de sélection adverse est que lorsque les personnes peuvent se permettre le luxe de choisir un salaire inférieur pour éviter des problèmes générant une douleur intense, elles le font. Si quelqu’un est déjà bien payé, il peut décider d’opter pour un emploi moins bien rémunéré mais qui présente l’avantage d’une douleur moins intense. La plupart des gens feraient probablement cela, et en pratique, beaucoup le font. Cela signifie que les personnes qui restent dans cette industrie, où il y a une très grande intensité de douleur ambiante, sont souvent celles qui ne peuvent pas se permettre de ne pas saisir l’opportunité d’un salaire plus élevé. Cela explique en grande partie pourquoi il y a un nombre important d’ingénieurs logiciels originaires d’Inde et d’Afrique du Nord. Ces pays disposent de systèmes éducatifs assez bons qui produisent des individus bien éduqués, mais les pays sont encore relativement pauvres. Les personnes dans ces positions n’ont pas le luxe de renoncer à des emplois d’ingénieur logiciel mieux rémunérés en raison de la forte demande et des salaires plus élevés par rapport à leurs salaires de base. Elles n’ont pas le luxe de choisir autre chose, et elles finissent donc par être très présentes dans l’industrie.

Il n’y a rien de mal avec ces pays ; c’est simplement une application mécanique des forces du marché. Ce n’est pas un jugement, juste une observation. Le fait est que la tolérance à la douleur ne suffit pas à faire un excellent ingénieur logiciel. C’est simplement une condition, mais si vous ne l’avez pas, alors vous n’êtes pas du tout un ingénieur logiciel. Cependant, si la tolérance à la douleur est la seule chose que vous avez, cela fera de vous un ingénieur logiciel assez médiocre. Du point de vue de la supply chain, la leçon ici est de prêter une attention particulière au type d’équipes que votre entreprise rassemble, que ce soit en interne ou par le biais de fournisseurs de logiciels. Assurez-vous que les ingénieurs rassemblés n’ont pas la tolérance à la douleur comme seule compétence, car cela signifie que vous obtiendrez un résultat très médiocre en termes de qualité logicielle et de valeur ajoutée du logiciel. Encore une fois, la tolérance à la douleur est nécessaire, mais ce n’est tout simplement pas suffisant.

En 1975, Frederick Brooks soulignait déjà que les mois-hommes ne représentaient pas la valeur créée par les logiciels et la valeur générée par les ingénieurs logiciels en général. Près de cinq décennies plus tard, les entreprises informatiques figurent parmi les plus grands employeurs du monde. En 2020, aux États-Unis, il y avait 3 millions d’employés dans l’industrie informatique, mais moins d’un million de personnes pour l’ensemble de l’industrie automobile. L’industrie informatique compte désormais au moins trois fois plus de personnes que l’industrie automobile. La plupart de ces entreprises informatiques, dont certaines sont absolument gigantesques avec plusieurs centaines ou milliers d’employés, ne facturent plus au mois-homme. C’était les années 70. Nous facturons maintenant au kilo-jours, ce qui équivaut essentiellement à mille jours de travail. La situation s’est sans doute beaucoup aggravée par rapport au problème que Frederick Brooks soulignait il y a près de cinq décennies, principalement en raison de l’augmentation incroyable de l’échelle et de l’ampleur du problème. Cependant, la plupart des premières leçons restent valables. “The Mythical Man-Month” reste un livre très intéressant sur l’ingénierie logicielle.

Dans le domaine du logiciel, la productivité varie énormément. D’un côté du spectre, vous n’avez pas des personnes avec une faible productivité ; vous avez des personnes avec une productivité négative. Cela signifie que lorsqu’elles commencent à travailler sur un produit logiciel, elles ne font qu’empirer les choses. Vous ne pouvez même plus faire un ratio entre la productivité des personnes. C’est bien pire que ça ; vous avez des personnes qui dégraderont activement votre produit. C’est un énorme problème. De l’autre côté du spectre, vous avez les soi-disant ingénieurs 10x, des personnes qui ont une productivité dix fois supérieure à celle d’un ingénieur moyen, qui espérons-le a une productivité positive. Ces ingénieurs 10x existent, mais cette productivité massive dépend énormément du contexte. Vous ne pouvez pas simplement transférer un ingénieur logiciel 10x d’une entreprise à une autre, voire d’un poste à un autre, et vous attendre à ce que cette personne conserve sa productivité incroyable. Habituellement, c’est une combinaison de compétences uniques et d’une situation spécifique qui génère cette productivité. Néanmoins, il est important de garder à l’esprit qu’un tout petit nombre de personnes peuvent générer la majeure partie de la valeur créée par un produit logiciel. Parfois, cela se résume à une seule personne qui crée la majeure partie de tous les éléments intelligents du logiciel et de la véritable valeur ajoutée, tandis que le reste traite de choses qui ont une valeur ajoutée douteuse au mieux. La leçon clé ici, identifiée il y a cinq décennies, est que lorsque vous êtes confronté à une échéance en supply chain, la seule option raisonnable à votre disposition est de réduire la portée de l’initiative logicielle. Toutes les autres options sont pires.

Ajouter des effectifs aggrave les choses, car il est souvent dit que l’ajout de personnel à un projet logiciel en retard le rend encore plus tardif. Cette déclaration de Brooks était valable il y a cinq décennies et l’est encore aujourd’hui. Les autres options ne fonctionnent pas non plus. Si vous commencez à faire faire des heures supplémentaires aux gens, cela se retournera contre vous car les gens seront fatigués et feront plus de bugs, retardant encore plus le produit. Si vous essayez de réduire la qualité, vous vous retrouverez avec quelque chose qui ne fonctionne plus. Ces choses vont échapper à tout contrôle et exploser entre vos mains, vous ne pouvez donc pas faire de compromis sur la qualité.

D’un point de vue de la supply chain, la leçon clé ici est que si vous vous attaquez à une initiative qui semble nécessiter plus de dix ingénieurs logiciels à temps plein, procédez avec la plus grande prudence. Habituellement, c’est un signe que c’est un problème très mal formulé. Il faut une incroyable collaboration pour que dix personnes travaillent simultanément sur le même produit tout en conservant leur productivité. Dans la supply chain, j’observe que les gens sont souvent trop ambitieux en termes d’échelle et de nombre de personnes impliquées. J’ai vu des projets de migration ERP avec 50, 100 ou 200 personnes qui y travaillaient simultanément. C’est absolument absurde. Pour parvenir à une quelconque forme de coopération, il faut des joueurs d’équipe incroyablement capables pour éviter de tout perdre à cause des frictions. Si vous avez des difficultés, gardez votre initiative logicielle concentrée, courte et étroite.

Ma dernière observation concerne une incompréhension fréquente concernant les grandes entreprises. La plupart des gens diraient que les grandes entreprises sont réticentes au risque, mais ce n’est pas mon expérience. Mon expérience est que les grandes entreprises sont réticentes à l’incertitude, pas au risque, bien que de loin, les deux puissent être confondus. De loin, l’explication rationnelle donnée est que les grandes entreprises sont réticentes au risque, mais en réalité, j’ai observé maintes et maintes fois que les grandes entreprises, lorsqu’elles sont confrontées à la possibilité de choisir entre un échec certain et un succès incertain, favoriseront invariablement la certitude de l’échec plutôt que le succès incertain.

Les grandes entreprises favoriseront invariablement la certitude de l’échec plutôt que le succès incertain, encore et encore. Cela peut sembler déconcertant et irrationnel en surface, mais ce n’est pas le cas. Les grandes entreprises ne sont pas une entité unique ; ce sont des bêtes politiques composées de nombreuses personnes. La politique et les apparences sont primordiales, surtout dans les structures très grandes.

Considérez le point de vue de celui qui est responsable d’une initiative logicielle. D’un côté, vous avez une initiative dont le résultat est certain - elle échouera. Cependant, vous jouez selon les règles, en suivant les règles, et tout le monde sait que cela échouera. Personne ne vous blâmera de jouer la sécurité et d’échouer car c’est ce qu’ils attendent. Au contraire, le succès incertain semble étrange. Poursuivre cette voie signifie faire des choses inhabituelles et potentiellement nuisibles pour sa carrière, bien plus que de simplement suivre les règles.

D’un point de vue de la supply chain, la leçon ici est que dans le monde du logiciel, il est extrêmement important de ne pas vous préparer à l’échec juste pour jouer selon les règles, surtout lorsque les règles sont complètement fausses. Par exemple, j’ai vu des entreprises échouer pendant des décennies en utilisant des méthodes comme l’analyse ABC et les stocks de sécurité, des méthodes qui peuvent être prouvées incorrectes et garantir l’échec des initiatives correspondantes. Ces méthodes sont erronées pour des raisons mathématiques et statistiques de base, il ne devrait donc pas être surprenant qu’elles échouent à apporter une valeur ajoutée dans la supply chain. Cependant, elles étaient considérées comme préférables car elles ne semblaient pas folles, étant du matériel de manuel.

Méfiez-vous du confort que vous pouvez obtenir en vous préparant à l’échec juste pour éliminer l’incertitude. Éliminer l’incertitude n’est pas le but ; le but est de maximiser les chances de succès, pas de réduire l’incertitude.

En conclusion, l’ingénierie logicielle est trop importante pour être laissée uniquement entre les mains des ingénieurs logiciels. Le logiciel est partout dans la supply chain et entraîne la mécanisation du travail intellectuel. Nous en sommes encore au stade précoce du processus, mais il peut déjà être dit, sans aucun doute, que les entreprises qui ne restent pas extrêmement compétitives sur ce front seront éliminées du marché par les forces du marché régulières. Pour la supply chain, le plus grand défi est culturel. Il ne s’agit pas d’un problème technique, mais d’un problème culturel. L’ingénierie logicielle remet en question notre façon de regarder et d’aborder les problèmes. La plupart des solutions intuitives ont tendance à être fausses, spectaculairement fausses.

En quelque sorte, l’ingénierie logicielle dans la supply chain consiste à apprivoiser le chaos, à apprivoiser toute la complexité et l’incertitude qui se trouvent partout dans la supply chain. Pour apprivoiser ce chaos, qui sera le travail des ingénieurs logiciels, si le processus lui-même est trop poli ou ordonné, s’il n’y a pas d’élément de chaos au cœur du processus, alors il n’y a plus de place pour le changement, le hasard ou la créativité. Ce qui est perçu comme de l’excellence se transforme rapidement en stagnation, puis en échec. Pour les entreprises plus traditionnelles, le plus grand défi de cette approche culturelle, en plus du choc culturel, est de renoncer à l’illusion du contrôle. Votre plan de migration ERP sur cinq ans est une illusion ; vous n’avez aucun contrôle sur un tel projet massif. De même, votre business case qui décrit les bénéfices attendus de votre initiative actuelle est également une illusion.

Lorsqu’il s’agit de mécaniser le travail intellectuel, le plus grand danger n’est pas de faire des choses que vous ne pouvez pas pleinement rationaliser. Le plus grand danger est de faire des choses qui sont complètement irrationnelles sous prétexte de rationalité.

Jetons un coup d’œil à la question. La prochaine conférence aura lieu le mercredi 15 décembre, à la même heure, 15h, heure de Paris, et elle portera sur la cybersécurité. Maintenant, je vais jeter un coup d’œil à la question.

Question : Comment mesurez-vous le retour capitaliste sur vos investissements logiciels ?

La plupart du temps, vous ne le faites pas. La mesure est le sous-produit de l’entreprise elle-même. C’est quelque chose de déconcertant si vous voulez mesurer le retour sur investissement. Cela suppose que vous pouvez trouver une mesure à l’avance, ce qui est généralement sous-entendu avec ce genre de question. Cela suppose que vous pouvez trouver cette mesure avant de construire votre étude de cas avec des scénarios, puis vous pouvez prendre une décision et passer ou non à votre investissement logiciel. Ce que je dis, c’est que cela ne fonctionne pas de cette façon avec les logiciels. C’est littéralement d’abord, vous faites la chose, puis vous apprenez ce qui doit être appris, et ensuite, en cours de route, vous apprendrez même quelles sortes d’avantages il y a. Pour guider votre action, vous avez besoin d’une compréhension globale. La leçon n’est pas de faire les choses au hasard, mais de ne pas faire des choses qui sont profondément irrationnelles sous prétexte de rationalité. L’intuition de haut niveau, si vous êtes absolument convaincu de quelque chose et que votre instinct vous dit que c’est le bon chemin, peut être un argument beaucoup plus rationnel par rapport à des calculs sophistiqués qui n’ont que l’apparence de la rationalité mais qui sont basés sur des chiffres erronés. La réalité est que, au fur et à mesure de votre entreprise logicielle, les mesures deviendront plus claires car vous commencerez à apprendre ce que vous essayez d’atteindre, puis vous apprendrez comment mesurer l’adéquation de ce que vous faites avec ce que vous devriez faire. La mesure est quelque chose qui viendra en tant que sous-produit si vous le faites bien. Cependant, en conséquence de cela, cela signifie que, en ce qui concerne les logiciels, il est beaucoup mieux d’essayer des choses et d’échouer rapidement. Vous ne voulez pas vous engager dans un engagement massif ; il vaut mieux le faire de manière incroyablement progressive, avec moins de personnes et une productivité élevée. Vous apprenez en cours de route comment procéder.

Mais alors vient un autre problème : dès que vous commencez à faire cela, la direction des entreprises doit être capable de jongler avec de nombreuses initiatives en même temps. Cela est très déconcertant, surtout pour les entreprises plus traditionnelles, car la direction ne s’attend pas à avoir autant d’initiatives allant dans différentes directions. Pourtant, c’est exactement ce qui se passe déjà dans les grandes entreprises de logiciels depuis des décennies maintenant, et c’est l’une des essences des enseignements de l’ingénierie logicielle d’un point de vue humain.

Question : N’est-ce pas une contradiction de dire que ceux qui ont de nombreux mots-clés ne s’associent pas à une technologie particulière ?

Eh bien, je ne dis pas que le fait d’avoir de nombreux mots-clés vous protège de vous associer à une technologie particulière. Ce sont deux problèmes différents. Le premier problème est celui d’une personne qui a une forte association entre son identité personnelle, son identité perçue et ses compétences. C’est le premier problème. Le deuxième problème est que la construction de votre CV est accompagnée d’un très fort conflit d’intérêts latent. Mon message est, d’un côté, méfiez-vous de ces politiques identitaires ; elles sont incroyablement toxiques. Mon deuxième message est méfiez-vous des conflits d’intérêts sous toutes leurs formes ; ils sont également incroyablement toxiques.

Maintenant, si vous mettez vraiment l’accent sur une technologie en particulier, vous pouvez supprimer certains mots-clés pour les technologies que vous désapprouvez sur votre CV. Cependant, en général, ces deux problèmes sont distincts, et vous pouvez même avoir quelqu’un qui dit : “Mon identité est que je suis un programmeur Python”, comme je l’ai montré dans une diapositive, et ensuite sur votre CV, mettre plus de 20 mots-clés. Les deux choses ne sont pas exclusives ; elles peuvent même se produire simultanément. De plus, ne sous-estimez pas le fait que parfois l’identité peut être associée à quelque chose d’aspirationnel, quelque chose que vous voulez acquérir. Vous pouvez dire : “Jusqu’à présent, j’ai programmé en Python, mais je veux devenir un programmeur Rust, donc je vais me considérer comme un programmeur Rust, bien que jusqu’à présent j’aie principalement fait du Python.” Toutes sortes de comportements sont possibles.

Question : L’ingénierie logicielle est considérée comme une science auxiliaire de la supply chain. Quelles seraient les sciences auxiliaires de l’ingénierie logicielle ?

Probablement la psychologie, la sociologie et l’ethnologie sont toutes des domaines pertinents en ce qui concerne l’ingénierie logicielle. Si vous commencez à l’aborder essentiellement comme l’interaction entre les personnes, alors ces sciences auxiliaires sont cruciales. Pour faire un travail sérieux en ingénierie logicielle, il ne s’agit pas uniquement de la technologie logicielle, bien que vous ayez besoin de comprendre le contexte logiciel pour que les interactions entre les personnes aient du sens. Vous n’avez pas nécessairement besoin de comprendre ce qui entre dans le code, mais vous devez comprendre des concepts tels qu’une base de code ou les outils qui existent et les problèmes qu’ils essaient de résoudre. Cependant, pour les besoins de cette série de conférences sur la supply chain, je dois tracer une ligne dans le sable, décider de ce que j’inclus et de ce que je n’inclus pas, car je ne peux évidemment pas couvrir tous les domaines de recherche.

Question : Demandez à dix personnes intelligentes une solution, et elles en trouveront plus de dix. S’accorder sur l’une des cinq meilleures et l’utiliser de manière cohérente est mieux. Comment équilibrez-vous ces deux approches et avantages contradictoires ?

C’est une question très large, mais si j’essaie de la cadrer dans le cas spécifique de l’ingénierie logicielle, vous pouvez avoir de nombreuses propositions, mais toutes ne doivent pas être considérées avec le même poids. Il existe une compétence qui consiste à avoir une vision à long terme du logiciel. Lorsque je dis que vous devriez vous concentrer sur ce qui ne change pas, il s’avère que certaines personnes sont très douées pour ce travail, et d’autres ne le sont pas. L’expérience entre en jeu lorsque vous voulez voir qui possède les compétences pour cette vision à long terme et ce qui ne change pas. À mon humble avis, il faut généralement à quelqu’un au moins 35 ans pour commencer à devenir très bon dans ce domaine, et les meilleurs sont âgés de plus de 60 ans. Il faut des années d’expérience pour voir le mouvement et les schémas.

Lorsque vous dites que vous avez autant de personnes, une illusion est que toutes ces solutions semblent bonnes, mais ce n’est qu’une apparence. Vous ne savez pas combien d’efforts il faudra pour tester les eaux. Pouvez-vous simplement prototyper ou le tester ? Parmi ces dix personnes, y en a-t-il certaines avec des compétences uniques pour identifier des solutions qui seront toxiques à long terme ? N’oubliez pas que vos coûts de maintenance sont essentiellement dictés par les décisions que vous avez prises. Y a-t-il une décision importante qui peut vous nuire à long terme ?

C’est un aspect délicat, et d’ailleurs, quelqu’un qui a une vision à long terme peut expliquer pourquoi une certaine option, à long terme, va générer toutes sortes de problèmes. Ce n’est pas juste une intuition. Ils vous diront : “Ce genre de chose, déjà vu, déjà fait. J’ai vu ça dans d’autres produits.” Il y a un dicton : l’homme intelligent apprend de ses propres erreurs, mais l’homme sage apprend des erreurs des autres. Cela s’applique très bien à ce cas.

Question : Comment les entreprises mesurent-elles l’augmentation de l’efficacité opérationnelle par dollar investi dans la mise en œuvre de logiciels pour les chaînes d’approvisionnement ?

C’est une question incroyablement difficile. Le problème est littéralement l’incommensurabilité des paradigmes. Cela vient de l’épistémologie ; l’idée est que lorsque vous passez d’un mode de fonctionnement à un autre, et que ces paradigmes sont radicalement différents, la plupart des mesures sont inutiles. Prenons l’exemple des ventes par téléphone par rapport au commerce électronique. Les sociétés de vente par correspondance existaient depuis le milieu du XIXe siècle. Si vous commencez à considérer le commerce électronique comme une amélioration par rapport aux sociétés de vente par correspondance, vous pourriez essayer de mesurer l’amélioration, mais la réalité est que pratiquement toutes les sociétés de vente par correspondance ont fait faillite. Les entreprises de commerce électronique qui dominent aujourd’hui sont plusieurs ordres de grandeur plus grandes que la plus grande société de vente par correspondance de tous les temps. Amazon est probablement 100 fois plus grande que la plus grande société de vente par correspondance historique, et la comparaison est très floue.

La mécanisation du travail intellectuel est tellement troublante et déconcertante parce que ce n’est pas comme le domaine physique. Avec la production physique, vous pouvez mesurer l’efficacité de manière canonique. Cependant, lorsque vous commencez à mécaniser votre travail intellectuel, qu’est-ce que l’efficacité signifie même ? Pour une entreprise comme Amazon, l’ensemble de sa chaîne d’approvisionnement est entièrement pilotée par des logiciels. Si les gens restaient simplement chez eux et ne faisaient rien, je suppose que toute la chaîne d’approvisionnement fonctionnerait très bien, même si tous ces ingénieurs ne faisaient rien pendant un jour ou deux. Alors pourquoi Amazon garde-t-elle ces ingénieurs ? Eh bien, parce qu’ils investissent dans leurs améliorations.

Au fait, une chose intéressante à propos de Jeff Bezos est son processus de gestion appelé “désaccord mais engagement”. Il dit qu’il y a des projets où son instinct de PDG lui dit que c’est faux, et il est en désaccord avec le projet. Cependant, il s’engage à soutenir le projet sur le plan budgétaire parce qu’il a embauché et fait confiance aux personnes qui y travaillent. C’est une approche un peu schizophrénique - en tant que PDG, il est censé être l’autorité ultime dans l’entreprise, mais il renonce à cette autorité et dit : “Je suis en désaccord, mais vous pouvez avoir le budget et continuer”.

La raison de cette approche est que les projets logiciels sont généralement assez bon marché. Si quelqu’un propose une idée apparemment folle qui n’est pas très coûteuse et ne mettra pas l’entreprise en faillite, pourquoi ne pas essayer ? Si cela fonctionne, cela pourrait être une idée brillante. Cela représente un choc culturel lors de la transition des entreprises traditionnelles de la chaîne d’approvisionnement, où la direction est censée avoir la vision et diriger les équipes. Dans le domaine du logiciel, le leadership consiste principalement à résoudre les problèmes qui surgissent parmi les ingénieurs logiciels.

Chez Lokad, lors de l’investissement dans des logiciels, la préoccupation principale n’est pas le retour sur investissement en dollars. Au lieu de cela, l’accent est mis sur le fait que l’investissement aborde un aspect fondamental de la gestion de la chaîne d’approvisionnement. S’il est essentiel à une grande variété de situations de chaîne d’approvisionnement, alors cela vaut la peine d’être poursuivi.

Par exemple, dans le secteur de l’après-vente automobile, s’attaquer au problème de la compatibilité mécanique est d’une importance primordiale. Vous ne vendez pas des pièces automobiles pour servir les personnes ; vous vendez des pièces pour servir les voitures. Une seule pièce peut être compatible avec plusieurs véhicules, et certaines pièces peuvent avoir des chevauchements mécaniques. Ce problème doit être résolu ; il est essentiel pour l’entreprise. Si vous ne le résolvez pas, quelqu’un d’autre le fera, et vous finirez par être évincé du marché.

En ce qui concerne les investissements dans les logiciels, il est important de prendre des risques et d’embrasser l’innovation, tant qu’ils ne menacent pas la stabilité financière de l’entreprise.

Question : Il est trompeur de dire que les grandes équipes de projet sont absurdes. Dans les systèmes ERP, une équipe de 10 personnes peut être suffisante pour le développement, mais les projets plus importants nécessitent plus de personnes. Il faut plus de personnes pour construire une tour que pour construire une maison. Pourriez-vous clarifier vos commentaires ?

Je vais prendre une position qui risque d’antagoniser beaucoup de gens. Les moyens de subsistance de millions de personnes dépendent de très grandes entreprises informatiques. Aux États-Unis en 2020, les entreprises informatiques représentaient trois millions d’employés américains. Donc, lorsque je dis qu’il n’y a absolument aucune raison d’avoir un ERP qui nécessite autant de personnes, évidemment, toutes les personnes qui gagnent leur vie en vendant de grandes équipes ou en faisant partie d’une telle équipe seront en désaccord avec moi de manière véhémente.

Mon contre-argument est le suivant : votre désaccord vient-il de raisons scientifiques fondamentales expliquant pourquoi le travail ne peut pas être fait avec moins de personnes, ou est-ce dans votre intérêt financier de maintenir le statu quo et d’avoir une armée de personnes pour faire le travail ? Si nous examinons toutes les innovations qui ont eu lieu - la destruction créatrice décrite par l’économiste Schumpeter - chaque fois qu’il y avait une innovation économique importante, il y avait généralement une amélioration massive de la productivité. Mais ceux qui étaient en retard se sont battus farouchement pour empêcher ces innovations de se produire.

Les ERP ne sont rien de nouveau ; ils existent depuis essentiellement quatre décennies. La plupart des ERP que je vois de nos jours n’apportent pas beaucoup de valeur par rapport à ceux que les entreprises avaient il y a un ou deux décennies. J’ai vu beaucoup d’anciens ERP qui fonctionnent très bien, et les nouveaux ERP ne sont souvent pas substantiellement meilleurs, surtout compte tenu des millions investis dans les projets de migration ERP. Dans ces projets massifs, je constate une productivité abyssale de la part des entreprises informatiques.

Mon contre-argument est de regarder des entreprises comme JD.com, Amazon ou Rakuten. Combien de personnes ces entreprises ont-elles besoin pour accomplir des tâches similaires ? En général, vous vous retrouvez avec des ratios insensés. Par exemple, Zalando, une grande entreprise européenne de commerce électronique basée à Berlin, en Allemagne, a construit son propre ERP avec une équipe plus petite que la plupart des équipes que j’ai vues pour des entreprises de taille similaire qui ont besoin de migrer leur ERP. Ainsi, d’un côté, vous avez une entreprise comme Zalando, capable de concevoir son propre ERP, entièrement adapté à ses besoins. Il fait très bien son travail en tant qu’ERP adapté à eux, et le coût et le nombre de personnes impliquées ne représentent qu’une fraction de ce dont ont besoin d’autres entreprises de taille similaire pour simplement effectuer une mise à jour de version. Le coût est encore une fois seulement une fraction. Je remets en question la nécessité d’impliquer autant de personnes, et c’est là le problème du travail de col blanc au XXIe siècle. Pour être un très bon employé, cela signifie que vous devez avoir le courage de vous automatiser, de vous rendre obsolète.

C’est quelque chose de très particulier. Lorsque les travailleurs manuels ont été rendus obsolètes, c’est par d’autres personnes que cela a été fait. Mais de nos jours, il ne reste presque plus de travailleurs manuels. Cela nécessite une mentalité différente, et c’est pourquoi il y a une lutte pour s’adapter à ce nouveau paradigme, principalement venant de l’industrie du logiciel. Il est bon de se rendre obsolète car on ne se rend pas réellement obsolète ; il n’y a pas de limite à l’ingéniosité humaine. On automatise simplement certaines tâches, ce qui nous libère pour relever le prochain défi, qui est encore plus intéressant que le précédent. Des entreprises comme Amazon ne licencient pas leurs ingénieurs logiciels dès qu’ils résolvent un problème. Elles les récompensent et les promeuvent pour relever le prochain problème, plus difficile.

En réponse à une question sur le fait que les praticiens de la supply chain sont bloqués dans une pensée analytique d’après-guerre, je suis d’accord que pour de nombreuses entreprises, pas toutes, l’ingénierie logicielle a évolué. Elle se définit comme un processus humain, ou un processus interprétatif. Je suis d’accord. L’industrie du logiciel ne se résume pas seulement à des technologies dures et fondamentales. Bien que certains postes requièrent des compétences techniques quantitatives incroyables, la majeure partie de l’industrie du logiciel se perçoit comme ayant une approche axée sur les personnes, une culture partagée.

Dans une large mesure, je pense que la domination des États-Unis et de la Silicon Valley dans le domaine du logiciel à travers le monde est due à la difficulté de reproduire leur culture. La culture a tendance à être très intangible et difficile à documenter. Lorsque vous la documentez, vous apprivoisez l’ingrédient chaotique nécessaire à l’innovation. Si vous documentez la culture, l’organisez et la traitez, vous perdez soudainement cet aspect d’émergence brute et chaotique des idées et des innovations.

Il existe des endroits comme la Silicon Valley où cette culture est prédominante, et ils sont en avance sur leur temps à cet égard. Pour conclure sur ce sujet, j’aimerais citer William Gibson, qui a dit : “Le futur est déjà là ; il n’est tout simplement pas uniformément réparti.” Je vois cette culture être maintenant reproduite à des échelles beaucoup plus petites dans de nombreux autres endroits, et le processus continuera et se développera avec le temps.

C’est tout pour aujourd’hui. À la prochaine. Dans notre prochaine session, nous discuterons d’un sujet qui peut être assez déprimant mais qui est très important : la cybersécurité. À la prochaine !