No Code, fin des codeurs ?

Les cimetières sont remplis de sociétés qui n’ont pas compris les règles du jeu.

Le codeur sera-t-il un jour relégué aux oubliettes ?

Contrôler les développeurs

Voilà une profession en plein boom, une profession de créateurs, une des rares à ne pas avoir été démolie par la révolution internet. Les estimations du nombre de développeurs varient selon les sources. Retenons celles de Slashdata qui prennent en compte les inscrits sur Github, Stack Overflow et npm, donc des codeurs: ils seraient 20 millions dans le monde (chiffre conservateur), en croissance de 20 % par an. Ils pourraient être 45 millions en 2030 minimum, un doublement en dix ans, d’après le consensus. 

Certes, ils sont à l’origine de la révolution du software et de l’internet (software is eating the world), mais leur création pourrait bien se retourner contre eux. Essayons de comprendre pourquoi. Les créateurs du monde d’avant internet avaient créé leur filière pour aller jusqu’au consommateur. Généralement, le coût de mise en place de cette filière était lourd et fixe, amorti sur un nombre considérable d’unités produites qui décourageait les nouveaux entrants, le consommateur était acquis:

• Les journalistes étaient affiliés à des journaux comprenant des salles de presse avec correspondants dans le monde entier, des imprimeries et des transporteurs pour déposer le journal jusqu’à la porte de l’abonné ou jusqu’au kiosque. Le nombre de journalistes était limité par cette infrastructure, ils avaient le statut de professionnel, une sorte de numerus clausus. L’internet a chamboulé ce bel équilibre, en donnant la possibilité à tout le monde de relayer une information, filmer une vidéo et la publier sur le champ. Tout à coup, il y avait 7,7 milliards de journalistes potentiels, le germe de la destruction était en place.

• Les acteurs passaient des contrats avec des agents qui les plaçaient auprès de réalisateurs et producteurs. l’ensemble de la chaine reposait sur le contact humain, donc une sélection limitée pour des films très coûteux distribués dans des salles de cinéma, puis en vidéo, avec un gros investissement marketing. La curation devient algorithmique, donc ouvre le champ des possible à  des acteurs de second rang d’abord (Netflix) puis à de nouveaux acteurs qui n’auraient jamais pu percer dans l’ancien système. L’échec de Quibi ( films courts avec le circuit traditionnel) est à mettre en regard avec TikTok qui donne la possibilité à ses 800 millions de membres de créer et pour les meilleurs de percer.

• Les créateurs de widget devaient trouver leur place dans un espace physique proche du consommateur. Cet espace, limité, a été dominé par la grande distribution qui privilégiait les produits de marques. Il y avait beaucoup de frais fixes et finalement peu d’élus pour trouver leur place auprès du consommateur. Avec l’internet, la barrière de l’espace disparait, tout créateur de widget peut lancer un site marchand sur Shopify, faire de la pub sur Facebook et trouver son public. Les barrières à la production tombent.

Qu’en est-il des développeurs ? A l’inverse des journalistes ou des acteurs, avant internet, ils n’avaient pas ou peu accès au client final, au travers d’une chaîne de distribution. Au début de l’informatique, les développeurs étaient liés à la machine: les instructions étaient manuelles puis constituées d’impulsions électriques qui impliquaient un formatage de la machine ! L’ordinateur devait être reconfiguré a chaque fois, processus tres fastidieux. Les gros ordinateurs et les programmeurs qui allaient avec se trouvaient dans les grands laboratoires de recherche ou les universités. L’ordinateur était surtout un super calculateur. Puis sous l’impulsion de Von Neumann notamment, l’ordinateur et le programme sont devenus autonomes. L’ordinateur a gagné en simplicité en devenant configurable, et les programmes ont introduit des routines facilement interprétables par le hardware. De plus, l’évolution des langages de programmation (l’orchestration des routines) a entrainé une diversification des usages, du calcul aux applications pour le monde des affaires, du FORTRAN d’IBM au COBOL, puis à l’Algol, ancêtre du langage C développé pour UNIX. Les développeurs ont quitté les laboratoires pour intégrer les entreprises. Et ils sont devenus un maillon essentiel de celles-ci, développant des applications propriétaires sur leurs serveurs. 

Microsoft et son OS standardidé Windows ont encouragé des développeurs à concevoir des logiciels potentiellement accessibles sur tous les PC équipés de Windows, donc ont donné une ouverture vers le client final. En même temps cette ouverture pouvait être fatale pour Microsoft, si une application devenait plus utilisée que Windows. C’est pourquoi Microsoft a cherché à contrôler les développeurs en les bloquant dans Windows, entraînant la réplique de l’Open source de la part de ces derniers (Linux). L’internet a amplifié le processus de libération des développeurs... et la réaction des agrégateurs. Il a rendu facilement accessibles des applications plug and play amorties sur un nombre considérable de clients qui sont venues déloger bon nombre de développements internes. Salesforce créé en 1999 a été la première application de masse, précurseur des nombreuses applications cloud. Dans les années 90, l’arme de Microsoft pour contrôler les développeurs était le standard propriétaire. Depuis l’avénement de l’internet, l’arme des agrégateurs est le client. Tout le jeu des agrégateurs est de détenir la demande, en proposant une capacité de choix sans pareille qui marginalement ne leur coûte rien (d’où leur préférence pour les biens digitaux). Cette détention de la demande leur permet de faire plier l’offre pléthorique à leurs conditions. Apple est un cas d’école de la relation ambivalente entretenue avec les développeurs: d’un côté leur donner accès au hardware, de l’autre dans des conditions strictement définies par Apple. La société se souvient en effet de la fin des années 90 où son sauvetage a dépendu de la compatibilité d’Adobe ou Office avec MacOS. Il n’est plus question de donner un tel pouvoir aux développeurs. Dans l’AppStore, Apple définit l’interface client et impose ses conditions aux développeurs. Jusqu’à la semaine dernière il pouvait bloquer une mise à jour pour un désaccord avec un développeur. Une des contraintes est de devoir payer 30% du chiffre d’affaires des biens digitaux vendus au travers de l’AppStore. Cela incite les applications à faire souscrire les abonnements en dehors de l’AppStore, sur le web, tout en laissant les utilisateurs utiliser l’app de l’AppStore. Apple considère cette manœuvre comme un détournement et cherche à obliger les fournisseurs d’application à payer sur l’AppStore ou à payer de toute façon même si l’abonnement est pris en dehors de l’AppStore. Apple va encore plus loin dans le contrôle des développeurs: en adoptant les puces ARM pour ses prochaines générations de Mac, il rapproche les systèmes d’exploitation du Mac, de l’IPhone et de l’IPad. Les développeurs vont se retrouver face à une base installée d’1,4 milliards d’appareils, ce qui ne favorise pas la négociation. Amazon, Microsoft et Google ont une autre façon de contrôler les développeurs: ils leur fournissent de nombreux outils, à travers leur offre cloud, pour développer. Dès lors cependant qu’une application perce, ils la copient et intègrent cette copie à leur offre cloud: le client étant acquis les frais de distribution sont zéro alors que l’application innovante doit payer Facebook ou Google pour se faire connaitre. C’est ainsi que MongoDB, qui devient le leader de la base de données documentaire se fait copier par DocumentDB lancé par AWS. C’est la stratégie Amazon Basic utilisée à l’encontre des marchands. De même, Zoom et Slack se font copier par Teams. ll y a une tentative de maîtrise des développeurs qui est d’autant plus forte que le succès des agrégateurs est dû à des développeurs eux même sortis du rang ! Car contrairement aux journalistes ou acteurs, les développeurs ne seront pas faciles à mettre au pas.

La force de la communauté

Il n’y a pas eu de tentative de contrôle des journalistes par Google ou Facebook, comme il n’y a pas de tentative de contrôle des acteurs, réalisateurs ou écrivains par Netflix ou Amazon, il n’en était nul besoin. En fait, il y a eu juste mise en concurrence de ceux-ci avec une multitude de nouveaux protagonistes qui n’avaient pas eu leur chance jusque là. Le jeu de la concurrence a exterminé les “experts adoubés” et renforcé la valeur de l’accès au client, si nécessaire pour se faire entendre dans un monde d’offre pléthorique. Les agrégateurs, ayant acquis cet accès au client, pouvaient le monétiser en faisant passer l’offre au tiroir caisse. 

La seule manière pour résister à la puissance des agrégateurs est d’avoir une offre qui ne se prête pas au jeu de la concurrence et ne peut être banalisée. C’est le cas dans l’industrie musicale où l’accès au catalogue historique est ce qui est le plus prisé. Les labels qui le détiennent font la loi, ce sont eux qui font durement payer Apple Music, Spotify ou Amazon pour avoir le privilège d’accéder à leur catalogue: le manche a changé de camp.

Il en est de même des développeurs. On ne peut pas les mettre facilement en concurrence pour deux raisons:

• ils ont la science du langage. Apprendre à coder prend du temps et demande de l’expérience pour structurer sa pensée, même si de nombreux organismes de formation se sont mis en place. L’apprentissage va de 3 mois pour les notions de base à quatre ans

C’est plus de temps qu’il n’en faut pour adapter l’offre à la demande, car le logiciel s’implante partout, si bien que les développeurs sont toujours en manque:

• Ils n’ont pas attendu les agrégateurs pour se mettre en concurrence ouverte et ainsi tirer le meilleur d’eux-mêmes. C’est le point le plus important, ce qui les différencie le plus des corporations protégées par une filière de distribution et qui se trouvent démunis quand le champ de la concurrence s’ouvre.

C’est toute  la différence entre une corporation et une communauté: la première cherche à se protéger de la concurrence tandis que la deuxième la désire comme un moyen de se faire reconnaitre par ses pairs. La règle de la première est de se protéger des assauts de la concurrence en s’alliant à la puissance publique (presse, banques) quand la règle de la deuxième est de contribuer de manière la plus ouverte possible au travail communautaire pour se faire admirer (on peut vouloir la communauté et être égoïste). La corporation s’ossifie quand la communauté se renforce. Ce n’est pas la vision habituelle que l’on a d’un univers concurrentiel. De Eric S Raymond dans The Cathedral and the Bazaar : 

Beaucoup de gens (surtout ceux qui se méfient politiquement des marchés libres) s'attendent à ce qu'une culture d'égoïstes autodirigés soit fragmentée, territoriale, gaspilleuse, secrète et hostile. Mais cette attente est clairement détrompée par (pour ne donner qu'un exemple) la variété, la qualité et la profondeur stupéfiantes de la documentation sur Linux. C'est un fait avéré que les programmeurs détestent la documentation ; comment se fait-il donc que les pirates de Linux génèrent autant de documentation ? Il est évident que le marché libre de l'egoboo de Linux fonctionne mieux pour produire un comportement vertueux et orienté autrement que les boutiques de documentation massivement financées des producteurs de logiciels commerciaux.

Les développeurs ont pris très tôt les habitudes de s’ériger en communauté productive. Unix a été le précurseur. Paradoxalement, c’est la position de monopole d’AT&T qui l’a poussé pour des raisons marketing à montrer qu’il était capable de créer un système ouvert. Unix est sorti des laboratoires Labs dans les années 70 avec pour vocation, comme l’a écrit un de ses fondateurs  Dennis Ritchie:

Ce que nous voulions préserver, ce n'était pas seulement un bon environnement pour faire de la programmation, mais un système autour duquel un compagnonage pouvait se former. Nous savions par expérience que l'essence de l'informatique communautaire, telle qu'elle est fournie par des machines à accès à distance et en temps partagé, ne consiste pas seulement à taper des programmes dans un terminal au lieu d'un clavier, mais à encourager une communication étroite.

La standardisation opérée par Microsoft autour de son système d’exploitation Windows, en en cachant le code source allait complètement à l’encontre d’Unix et de sa philosophie collaborative. Elle cherchait simplement à rendre les développeurs dépendants de Windows, à les contrôler. Linus Torvalds s’est érigé contre ses pratiques en faisant sortir d’Unix un système d’exploitation complètement ouvert, fondé sur le principe communautaire d’auto-amélioration concurrentielle: Linux. Les partages communautaires entre développeurs se sont accélérés depuis, facilités par l’internet, et la méthode Linus Torvalds. D’après The Cathedral and the Bazaar:

Linux a été le premier projet pour lequel un effort conscient et réussi a été fait pour utiliser le monde entier comme réservoir de talents. Je ne pense pas que ce soit une coïncidence si la période de gestation de Linux a coïncidé avec la naissance du World Wide Web, et que Linux a quitté ses balbutiements pendant la même période en 1993-1994 qui a vu le décollage de l'industrie des fournisseurs d'accès Internet et l'explosion de l'intérêt général pour l'Internet. Linus a été la première personne à apprendre à respecter les nouvelles règles que l'accès omniprésent à l'internet a rendues possibles.

Si un Internet bon marché était une condition nécessaire à l'évolution du modèle Linux, je pense qu'elle n'était pas suffisante en soi. Un autre facteur vital était le développement d'un style de leadership et d'un ensemble de coutumes coopératives qui pourraient permettre aux développeurs d'attirer des co-développeurs et d'obtenir un maximum d'effet de levier de ce média.

Mais quel est ce style de leadership et quelles sont ces coutumes ? Elles ne peuvent pas être basées sur des relations de pouvoir et même si elles le pouvaient, le leadership par la coercition ne produirait pas les résultats que nous constatons. Weinberg cite l'autobiographie de l'anarchiste russe du XIXe siècle, les Mémoires d'un révolutionnaire de Pyotr Alexeyvich Kropotkin, à ce sujet :

Ayant été élevé dans une famille de serfs-propriétaires, je suis entré dans la vie active, comme tous les jeunes hommes de mon temps, avec une grande confiance dans la nécessité de commander, d'ordonner, de gronder, de punir et autres. Mais lorsque, très tôt, j'ai dû gérer des entreprises sérieuses et traiter avec des hommes [libres], et que chaque erreur entraînait immédiatement de lourdes conséquences, j'ai commencé à comprendre la différence entre agir selon le principe du commandement et de la discipline et agir selon le principe de la compréhension mutuelle. Le premier fonctionne admirablement dans un défilé militaire, mais il ne vaut rien dans la vie réelle, et le but ne peut être atteint que par l'effort sévère de nombreuses volontés convergentes.

L'"effort sévère de nombreuses volontés convergentes" est précisément ce qu'exige un projet comme Linux. Et le "principe de commandement" est effectivement impossible à appliquer entre volontaires dans le paradis des anarchistes que nous appelons Internet. Pour fonctionner et rivaliser efficacement, les pirates informatiques qui veulent mener des projets de collaboration doivent apprendre à recruter et à dynamiser des communautés d'intérêt efficaces selon le mode vaguement suggéré par le "principe de compréhension" de Kropotkin. Ils doivent apprendre à utiliser la loi de Linus [SP].

Les développeurs ont créé une communauté extrêmement solide, fondée sur la libre concurrence collaborative. Cette communauté est aussi solide qu’un label face aux sites de streaming musical...et capable d’innovation pouvant mettre en danger les agrégateurs. On comprend la volonté de ces derniers de les contrôler, non plus avec le standard car c’est maintenant anathème, mais avec la puissance de leur base de clients/utilisateurs.

Escarmouches

Les positions sont bien équilibrées:

• D’un côté les agrégateurs cherchent à 1/empêcher les développeurs d’avoir leur propre clientèle, 2/ monétiser leur puissante base de clients, 3/ capter les innovations potentielles les plus prometteuses en les copiant.

• De l’autre des développeurs qui ont créé une machine culturelle à innover, cherchent leurs propres moyens d’accès aux clients (passant par la maîtrise du paiement, donc par le bon vieux site internet). Les développeurs peuvent utiliser leur forte communauté pour décrier un agrégateur et nuire à sa réputation dans l’œil du grand public (la plus grande crainte de l’agrégateur).

Et la lutte s’intensifie ces derniers temps. Le cas de Basecamp est révélateur des armes utilisées par les uns et les autres. Cette société a lancé une application de tri d’emails, nommée Hey. Pour éviter la taxe de 30% et garder le contact exclusif avec son client, Hey ne permet pas la souscription du service par l’AppStore, mais uniquement par son site. Apple, estimant que de plus en plus d’apps utilisent ce stratagème a décidé de bloquer la nouvelle version de Hey, jusqu’à ce que ce dernier autorise la souscription par l’AppStore. La réaction de Basecamp est tout à fait intéressante dans la mesure où elle montre bien que le fonds du problème est la captation du client par Apple et que la révolte gronde ! De Jason Fried, PDG de Basecamp:

Vendredi 19 juin 2020

Jusqu'à présent, la plupart des discussions récentes sur Apple, HEY, In App Purchase (IAP), les abonnements, l'App Store et la communauté des développeurs iOS ont porté sur l'argent.  Une réduction de 30 % est-elle équitable ?  Que diriez-vous de 15% ?  Et si c'était 5% ?

Et certains se disent : "Pourquoi ne pas simplement avoir un prix spécial in-app qui est 30% de plus que votre prix habituel ?  Il suffit de répercuter la taxe Apple sur les clients ?"  Parce que là n'est pas la question.

Je ne nierai pas que l'argent, ou la vigueur, dans ce cas, est une grande partie de l'histoire.

Mais personnellement, en tant que propriétaire d'une entreprise, ce n'est pas seulement une question d'argent.  L'argent fait les gros titres, mais il y a une histoire beaucoup plus élémentaire ici.  Il s'agit de l'absence de choix, et de la façon dont Apple s'insère de force entre votre entreprise et votre client.

La plus grande entreprise du monde peut-elle vraiment décider de la manière dont des millions d'autres entreprises peuvent interagir avec leurs propres clients ?  En fait, la politique d'Apple vous éloigne de votre client.

Lorsqu'Apple oblige les entreprises à proposer des achats In App pour être sur leur plateforme, elle dicte également les limites dans lesquelles vous pouvez aider votre client.  Cela a un impact négatif sur l'expérience client et sur votre relation avec votre client.  Cela peut carrément ruiner une interaction, nuire à votre réputation et vous coûter littéralement des clients.  Elle nous empêche de fournir un service clientèle exceptionnel lorsqu'une personne qui utilise notre produit a besoin d'aide.

Je vous encourage à lire l’intégralité de l’article qui montre bien comment un agrégateur subtilise le client et vide l’innovateur de son oxygène. Basecamp se fait le porte-voix d’une portion croissante de développeurs:

Et le très influent CTO de Basecamp sonne la charge:

La charge a été efficace, Apple a dû plier lors de sa dernière conférence des développeurs. C’est un signe de l’excellente résistance de cette profession:

Une deuxième illustration des escarmouches que se livrent développeurs et agrégateurs est l’exemple de MongoDB face à AWS. MongoDB est une base de données documentaire nouvelle génération open source. L’open source qui fait la force des développeurs est aussi leur faiblesse: un agrégateur peut facilement copier et s’appuyer sur sa base de clients pour les marginaliser. C’est ce qu’AWS a tenté de faire avec sa propre base de données documentaire DocumentDB. La réplique de MongoDB est d’exiger pour ses nouvelles versions que le copieur révèle l’intégralité de son code en open source. Cette exigence est rédhibitoire pour AWS qui doit s’accommoder d’’une ancienne version, laissant ainsi à MongoDB le leadership.

Le pouvoir des développeur, leur capacité de faire front et de “ringardiser” un agrégateur est clairement manifesté dans l’acquisition de Github par Microsoft en 2018. Avec Satya Nadella, Microsoft a compris que le standard propriétaire avait perdu de sa puissance, le relai ayant été pris par la base clientèle: Windows out, open source cloud in. Microsoft est devenu un agrégateur de clientèle entreprise auquel il cherche à vendre un maximum de services digitaux à coût marginal nul. Le problème est que les développeurs ne viennent pas quémander auprès de Microsoft, échaudés par la stratégie ancienne de “lock in” pratiquée par Windows. Microsoft a une image à réparer: son acquisition de Github, le plus important hébergeur de code open source au monde est un moyen de se faire accepter par ses 24 millions de contributeurs.

Microsoft a donc choisi la conciliation avec les développeurs, mais la relation reste ambiguë...La société n’a aucun scrupule à copier Slack ou Dropbox quand il s’agit d’enfermer le client dans son offre. Microsoft donne des outils aux développeurs et se fait indirectement financer sa propre innovation...Ce n’est pas tombé dans l’oreille d’un sourd: Google voit dans cette attitude de Microsoft un moyen de se positionner sur le cloud: pour compenser sa faiblesse au niveau de la clientèle entreprise, la société joue à fonds les partenariats avec les développeurs indépendants, la carte de l’innovation.

No Code

Finalement, pour sortir de cette relation de pouvoir trop équilibrée à leur goût, les agrégateurs n’ont qu’une solution: faire comme avec les acteurs ou journalistes, c’est à dire ouvrir le champ de la concurrence entre développeurs au monde entier, mettre fin au monopole des codeurs. Cela explique leur intérêt de plus en plus prononcé pour le no code.  De Znet, le 25 juin 2020:

Amazon Web Services a lancé ce mercredi Amazon Honeycode, un service entièrement géré qui permet aux entreprises de créer des applications mobiles et web sans aucune programmation. Les clients peuvent utiliser le service pour créer des applications exploitant une base de données construite par AWS, comme une simple application de suivi des tâches ou une application de gestion de projet plus complexe pour gérer plusieurs flux de travail.

« Les clients nous ont dit que le besoin d'applications personnalisées dépasse de loin la capacité des développeurs à les créer », explique Larry Augustin, vice-président d'AWS, dans un communiqué.

Les outils à faible code ("low code") et sans code ("no code") ont connu une popularité croissante ces dernières années, permettant à des personnes ayant peu ou pas d'expérience en matière de codage de pouvoir créer les applications dont elles ont besoin. D'autres grandes entreprises de cloud computing comme Salesforce proposent des créateurs d'applications "low code". Les équipes informatiques ayant été mises à rude épreuve pendant la pandémie de Covid-19, les outils "low code" et "no code" peuvent s'avérer particulièrement utiles.

L’évolution d’IOS14 est également parlante. Le widget est omniprésent au milieu des apps. Le widget est la brique de base pour construire un site web ou une application sans code. Apple s’était déjà engagé des 2010 dans la voie de la simplification du langage avec Swift, afin de rendre le code accessible au plus grand nombre. Cependant, la part de marché de swift est restée marginale, il fallait aller plus loin dans la simplification pour attirer des développeurs.

On voit bien l’intérêt pour les agrégateurs de pousser le no code: 

1. Limiter le pouvoir des codeurs en leur imposant une concurrence potentiellement massive.

2. Rendre les développeurs dépendants de leurs outils (le code servant à construire les widgets)

3. Bénéficier des meilleures innovations pour consolider leur clientèle.

La profession des développeurs ne voit pas la menace. Le no code est perçu comme un bouche trou (compensant le manque de codeurs) et limité dans ses fonctionnalités. L’argument est que le codeur est plus proche de la machine et que le no code n’est après tout qu’un recyclage de briques de code: pas de no code sans code...Pour preuve, le no code existe depuis des années, Excel en est la parfaite illustration et n’a jamais déplacé le codeur...

C’est oublier un peu vite la théorie des technologies de rupture développée parClayton Christensen dans The innovator’s dilemma. D’après Wikipedia:

Une technologie de rupture (dite aussi rupture d'innovation ou  technologique rupture) est une innovation technologique qui porte sur un produit ou un service et qui finit par remplacer une technologie dominante sur un marché.

Cette disparition de la technologie existante se fera bien que la technologie de rupture soit radicalement différente et qu’elle soit souvent moins performante à l’origine selon les critères traditionnels de mesure. Une technologie de rupture survient et domine un marché déjà existant soit en remplissant une fonction que la technologie traditionnelle ne pouvait pas remplir pour une application particulière (comme ce fut le cas des petites disquettes initialement plus chères et de capacité réduite développées pour les ordinateurs portables) ou bien en augmentant progressivement les parts de marché au fur et à mesure que les performances augmentent, jusqu’à remplacer ceux qui étaient établis sur le marché (comme ce fut le cas avec la photographie numérique).

C’est toujours difficile de l’intérieur de voir une technologie de rupture car elle ne s’adresse pas initialement au marché habituel et est moins performante. Une app no code permettra à de nombreux projets de s’exprimer alors qu’ils n’auraient jamais sauté le pas d’embaucher un codeur. De telles apps pourront représenter des projets plus imaginatifs mais pourront difficilement évoluer...au début. 

Le cœur de la critique est que le no code sera toujours un recyclage de code et donc moins proche de la machine, moins intégré et moins performant (vitesse d’exécution notamment). cela m’inspire deux réflexions:

• Les deux concepts de base qui ont permis de faire progresser la programmation ont été 1/ de séparer le hardware des instructions, 2/ d’utiliser des routines de code facilement recasables. De Andrew Fergusson:

En 1945, John Von Neumann travaillait à l'Institute for Advanced Study. Il a développé deux concepts importants qui ont directement affecté la voie des langages de programmation informatique. Le premier était connu sous le nom de "technique des programmes partagés" (www.softlord.com). Cette technique stipulait que le matériel informatique réel devait être simple et ne devait pas être câblé à la main pour chaque programme. Au lieu de cela, des instructions complexes devaient être utilisées pour contrôler le matériel simple, ce qui permettait de le reprogrammer beaucoup plus rapidement.

Le deuxième concept était également extrêmement important pour le développement des langages de programmation. Von Neumann l'a appelé "transfert de contrôle conditionnel" (www.softlord.com). Cette idée a donné naissance à la notion de sous-programmes, ou de petits blocs de code auxquels on peut accéder dans n'importe quel ordre, au lieu d'un seul ensemble d'étapes chronologiquement ordonnées que l'ordinateur doit suivre. La deuxième partie de l'idée stipulait que le code informatique devait pouvoir se ramifier sur la base d'instructions logiques telles que IF (expression) THEN, et être bouclé comme avec une instruction FOR. Le "transfert de contrôle conditionnel" a donné naissance à l'idée des "bibliothèques", qui sont des blocs de code pouvant être réutilisés à l'infini.

En ce sens, le no code n’est qu’une prolongation de la tendance qui a permis à l’informatique de décoller.

• Les codeurs qui ne  voient pas comment leur science pourrait être disruptée devraient garder en mémoire l’histoire de Nucor, le champion de l’acier  aux Etats-Unis. Nucor ne recyclait pas du code mais de l’acier. Dans les années 60, le procédé pour fabriquer de l’acier était toujours le même depuis un siècle: l’acier Bessemer. Les sidérurgistes utilisaient des haut-fourneaux où ils fixaient les éléments indésirables de la fonte avec de l’oxygène pour en tirer de l’acier. Le procédé était complexe et coûteux, c’était une barrière à l’entrée qui protégeait les grandes sociétés sidérurgiques (tout comme la connaissance du langage protège les codeurs). Arrive le lilliputien Nucor qui décide d’implanter dans les provinces des Etats-Unis, où la main d’oeuvre est bon marché, des mini-fourneaux qui recyclent de l’acier: le procédé est très bon marché, la matière première aussi, mais on se dit que le recyclage ne peut être qu’une niche, dépendant de la production d’acier (comme le no code dépend du code). Résultat: Nucor peut fixer le prix de son acier à $ 10/15 de moins que ses lourds compétiteurs tout en réalisant des marges supérieurs. Quelques années plus tard, ils succombent tous, sauf Nucor qui est resté le fleuron de l’industrie sidérurgique américaine et reste la seule côtée avec une capitalisation boursière non négligeable et un bon parcours boursier. Le produit recyclé peut tuer le produit principal, c’est la leçon de Nucor.

Il reste néanmoins de grandes différences entre les codeurs et les journalistes ou auteurs, entre les codeurs et les sidérurgistes des années 60: d’une part, la demande de développeurs est explosive et il faut aller très vite dans cette industrie. D‘autre part les développeurs codeurs ont trouvé un mode d’organisation en open source avant-gardiste, par le partage concurrentiel, qui les rend redoutablement efficaces. Les développeurs non codeurs ont tout à construire de ce coté et partent donc avec un handicap de taille. 

Le rapport de force entre développeurs et agrégateurs risque de durer longtemps. La position conciliatrice de Microsoft (Achat de GitHub, adoption de l’open source, mise à disposition d’outils, etc.) est intelligente car elle tient compte de ce rapport de force pour tirer meilleur des développeurs. Mais la suspicion reste forte car Microsoft a l’art de copier et intégrer. Google joue sur cette suspicion pour proposer de réel partenariats avec les développeurs et faire avancer ainsi son offre cloud , en retard. Les développeurs restent un enjeu de taille...