Skip to content

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. 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
, 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
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:
Limiter le pouvoir des codeurs en leur imposant une concurrence potentiellement massive.
Rendre les développeurs dépendants de leurs outils (le code servant à construire les widgets)
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
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...
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.