Le développement web face à l’IA : rupture ou continuité ?
Écrire un article de réflexion sur le thème du développement web, alors qu’aujourd’hui l’IA est partout et ouvre la porte à un grand nombre de personnes qui ne sont pas forcément développeurs… Qu’en est-il ? Que doit-on en déduire ? Et surtout, au fond, quel avenir pour le développement ?
Avant toute chose, il faut voir dans ce sujet un réel questionnement, presque une forme d’introspection personnelle, car il serait bien prétentieux de ma part de prétendre avoir la réponse à un tel paradigme, surtout face à une telle révolution.
Des interfaces aux intentions
Je me souviens qu’il y a quelques années, des outils comme Dreamweaver sont apparus dans le paysage du développement web alors en devenir, en proposant une nouvelle manière de produire du code. Cela permettait de répondre plus facilement, et surtout plus rapidement, à la demande de création d’interfaces statiques. Les tableaux HTML imbriqués se construisaient au travers de boîtes de dialogue, les premiers comportements utilisateurs apparaissaient sans avoir à écrire chaque ligne manuellement.
Puis Drumbeat, rapidement transformé en UltraDev, est venu prolonger cette logique en ajoutant les premiers comportements serveurs. L’idée n’était déjà plus seulement d’écrire du code, mais de produire plus vite des fonctionnalités et des services.
Avec HomeSite venant rejoindre et compléter cette panoplie, la génération progressive des CSS en arrière-plan devenait transparente. Une partie du développement commençait déjà à se déplacer vers l’assistance et l’automatisation.
Et quelque part, on voyait déjà Dreamweaver se transformer au fil des rachats et des intégrations opérées par Macromedia. Drumbeat, UltraDev, HomeSite… toutes ces briques venaient progressivement enrichir l’environnement de travail, jusqu’à faire évoluer Dreamweaver d’un simple éditeur visuel de pages web vers un véritable atelier de production de services et d’interfaces dynamiques.
Quelle ne fut pas alors la controverse… D’un côté se regroupaient ceux qui savaient faire sans ces pseudos-aides, qualifiant les autres, ceux qui faisaient avec, d’apprentis sorciers n’étant pas à même de contrôler ou comprendre la moindre page qu’ils construisaient… Ce qui parfois s’avérait malheureusement vrai.
Fallait-il alors s’orienter vers le développement uniquement fait main depuis une page blanche et s’initier aux langages, qui à l’époque étaient encore très propriétaires, ou avoir recourt à ces nouveaux outils qui commençaient à intéresser un bien plus large public ? La réponse des éditeurs a alors été de produire des extensions et des outils de contournements, qui permettaient de repousser, encore plus loin, les limites et de franchir des caps, de débrider les outils parfois maladroits, ou incomplets… InterAKT, DMX Zone, Web Assist, Project Seven…
Et puis sont arrivés les outils “tout intégrés”, qui eux, proposaient des interfaces modulaires et dynamiques, où il suffisait d’entrer du contenu, d’activer des fonctionnalités depuis une interface “tableau de bord”, et d’en ajouter si celles-ci n’étaient pas suffisantes.
Dorénavant un collectionneur passionné de papillons pouvait démarrer son activité en deux clics… sans connaitre de langages autre que celui des papillons.
Les CMS ayant débuté pour la plupart comme de simples outils de gestion de blogs, ont vite donner lieu à une véritable remise en question des développeurs qui, pour la plupart, continuaient toujours à produire du contenu en partant à chaque fois d’une page blanche.
La question n’était plus : comment développer… mais quoi développer… ?
Cette question est restée sous le tapis, avalée par le rouleau compresseur du web qui se construisait. Peu importait alors le savoir, le comprendre, le pourquoi, ou même le comment, pourvu que cela se fasse. Le web devait se remplir. Absorber toujours plus d’informations, toujours plus de données. Une forme de boulimie numérique commençait déjà à apparaître. Petit à petit, les lignes de code laissaient place aux datas. Peu à peu, les interfaces se sont mises à se ressembler.
Les CMS, les frameworks et les plateformes de diffusion ont imposé leurs propres logiques d’organisation, leurs conventions, leurs habitudes de navigation. Derrière les notions d’UI et d’UX se dessinait déjà une certaine uniformisation de notre manière d’accéder aux contenus, et progressivement, d’interpréter l’information.
Dans la chaine de l’évolution du développement web, après la phase de standardisation et d’apprentissage des langages, il a fallu absorber des masses de contenus digérés par des serveurs, puis les redistribuer sur des interfaces web adaptatives et responsives, capables de se métamorphoser au gré des périphériques de lecture.
Quand un nouveau projet se présentait, quelle approche les développeurs allaient-ils adopter :
- Allaient-ils partir d’une page blanche ?
- Allaient-ils s’appuyer sur des plateformes de diffusion ?
- Allaient-ils au contraire avoir recours à des Frameworks prêts à distribuer les contenus de manière quasi imposées ?
- Ou encore allaient-ils utiliser des Templates, qui sont aujourd’hui publiés par centaines et auxquels on accède pour seulement quelques dollars ?
L’IA aujourd’hui n’est sans doute que la continuité de cette longue évolution, mais avec une toute nouvelle interface : le prompt.
Après les boîtes de dialogue, les palettes flottantes, les assistants de génération et les tableaux de bord, nous nous retrouvons désormais face à un simple champ de texte, derrière lequel se dissimule un interprète capable de transformer une intention en structure exploitable. Même Photoshop, devenu l’emblème historique de l’image picturale, après avoir en son temps détrôné Live Picture, propose aujourd’hui, lui aussi, sa palette “prompt”… c’est dire !
La question n’est alors plus seulement de comprendre comment développer, ni même quoi développer. Elle se déplace progressivement vers le processus à mettre en œuvre pour transformer une intention en service cohérent. Et c’est précisément là qu’apparaît aujourd’hui cette nouvelle rupture. Après les interfaces graphiques, les générateurs de code, les CMS, les frameworks et les plateformes de diffusion, l’interface elle-même semble se réduire à une simple formulation textuelle : le prompt.
Une idée, une intention, une demande exprimée en langage naturel, deviennent alors capables d’orchestrer des contenus, des structures, des services ou simplement… du code. Le développement, lui, semble progressivement se déplacer des seuls langages et technologies, vers les notions de sens, de service et d’orchestration. Le paradoxe est que, sans connaitre les langages (leurs bases), ni les technologies (leurs articulations et leurs enchevêtrements), il devient alors difficile de faire appel à un interprète d’idées, dissimulé derrière un simple champ de formulaire… derrière un simple prompt.
Encore faut-il, également, être à même de lire d’un œil critique la réponse qui sera formulée… Sans un minimum de bases, cela consiste à être prêts à accepter la pire des incohérences que l’on ne découvrira qu’une fois face à un blocage, face aux incontournables et multiples bogues, ou mal fonctions. Dessine-moi une appli… ? !
Aux origines des interfaces conversationnelles
Prenons quelques instants… Prenons un peu de recul… pour mieux savoir vers où l’on est en train d’aller.
Revenons au point de départ, au moment où, comme des explorateurs numériques, lampe frontale allumée, souris et clavier à la main, nous partions explorer ce nouvel environnement qu’était le web. Ce nouveau terreau fait de virtualité, d’imaginaire, et de promesses… à l’époque où s’est forgée « Une certaine idée du développement ».
Il me revient à l’esprit quelques ouvrages qui m’ont marqué à leur époque, mais aussi une remarque qu’un ami avait formulée au cours d’une journée de travail consacrée à la création d’interfaces dynamiques… Arnaud m’avait alors dit quelque chose comme : « … mais comment vous faisiez avant que le web existe ? » Cette question, qui peut sembler antédiluvienne, révélait pourtant déjà ce web “savant”, expérimental et précurseur, qui commençait à apporter des pistes, des réponses, ou du moins des manières nouvelles d’envisager les problèmes. Et au fond, ces livres participaient déjà à cette même exploration. Ils ne donnaient pas toujours des solutions concrètes, mais ouvraient des chemins, des projections, des façons d’imaginer comment le web pourrait être abordé.
Je me souviens la première fois que j’ai découvert en 1993 cette couverture, « Mind over Media : Creative Thinking Skills for Electronic Media »… où l’auteur grâce à des schémas et des modèles, nous permettait d’explorer, de projeter, d’envisager, et surtout de mettre à plat, la manière dont nous allions pouvoir combiner ce que la souris, l’interaction et l’interactivité, sans oublier les différents médias, pourraient produire comme interfaces utilisateurs.
Et puis… et puis… la rencontre avec Peter Small… du moins au début avec son premier ouvrage, « Lingo Sorcery », où en 1998, il proposait déjà une autre manière d’aborder la programmation, en repensant la relation entre l’objet, l’interaction et l’interface. Ensuite, avec « Magical A-Life Avatars », il poursuivait cette réflexion en plaçant cette fois le document au centre de l’application, et non plus en mettant l’application au service du document. Enfin, pour finaliser ce triptyque de réflexion, il a réuni autour de lui tout un groupe de travail qui s’était progressivement formé autour de Lingo-L (forum de discussion à propos de Macromedia Director), afin de donner naissance à « The Entrepreneurial web ». Expérience à laquelle j’ai eu la chance de pouvoir participer. La finalité consistait à projeter à partir du chaos que le web naissant dessinait, l’arbre des possibles, et une fois encore mettre à plat ce qui était en gestation, ce qui pouvait en être, en devenir, en ressurgir… participer à la dématérialisation de l’interface pour mieux la reconstruire, en la personnalisant, en l’adaptant réellement aux besoins de l’utilisateur et non l’inverse.
On dépassait l’application… on dépassait le document… on explorait l’adaptation du service aux réels besoins de l’utilisateur.
A cette même époque des sociétés comme Realviz, travaillaient également sur la compréhension du pixel, de l’image, de sa reconstruction et de son interprétation. Là où les moteurs de recherche commençaient à tenter de comprendre le sens d’une demande textuelle, d’autres cherchaient déjà à interpréter le sens pictural d’une scène photographique.
Ils étaient capables de proposer des interfaces à l’apparence volumétrique, en partant d’images photographiques projetées sur des surfaces ou des écrans plats. Il devenait envisageable de ne plus apprendre à modéliser en 3D, ou à programmer des meshs, mais simplement de se servir d’un appareil photo, et de laisser faire la machine.
Le web continuait à évoluer. Les interfaces s’affinaient, les langages se multipliaient entre clients et serveurs, pendant que les bases de données développaient elles aussi, leurs propres logiques, leurs propres syntaxes, leurs propres mécanismes.
Fallait-il alors tout apprendre, tout maîtriser, tout comprendre ? Ou fallait-il accepter que le développement devienne progressivement un travail d’orchestration entre couches techniques, outils, services et abstractions successives ?
Comme toujours, même en creusant, même en décortiquant, les questions devenaient multiples, et restaient le plus souvent sans réponse. Il fallait continuer à fureter, observer, fouiller, prospecter.
Quelques années plus tard… en roulant sur l’autoroute entre Montpellier et Nîmes, tard dans la nuit, la radio allumée, sans doute France Culture, il y a eu cette émission consacrée aux moteurs de recherche. Nous étions alors en pleine bascule entre la perte de vitesse d’AltaVista et l’émergence de Google. La personne invitée, dont j’ai oublié le nom, expliquait que la personnalisation de la recherche pouvait tout autant être une richesse, qu’un piège.
La problématique étant d’éviter l’écueil qui enfermerait l’utilisateur dans une case dont il lui serait difficile de sortir. La recherche devait avant tout s’entourer de découvertes, d’extériorisations, et non d’enfermement, de réduction, d’assignation, de formatage. Et surtout, il y avait cette stigmatisation, omniprésente, de la recherche par mot clé. Les moteurs fonctionnaient alors principalement sur des correspondances exactes. Il fallait trouver le bon mot, la bonne formulation, presque apprendre à parler leur langue.
Très vite, une autre problématique est apparue. Comment interpréter les variantes, les synonymes, les fautes d’écriture, les formulations approximatives, les intentions mal exprimées ? Si l’utilisateur cherchait “voiture”, allait-il écrire automobile, véhicule, auto, ou simplement “bagnole”, parfois même mal orthographié ?
Petit à petit, les moteurs ont commencé à observer ces usages, écouter les comportements, rapprocher les formulations, interpréter les contextes. La recherche ne portait plus uniquement sur les mots eux-mêmes, mais progressivement sur le sens de la demande.
La recherche par compréhension du langage naturel n’est réellement apparue, avec Hummingbird, qu’au début des années 2010… et l’ouverture après COVID de la réelle approche conversationnelle grâce à RankBrain et BERT. Cela a permis de commencer à réellement dialoguer avec les moteurs de recherche… le fameux champ de recherche unique proposé par AltaVista, et enrichit par Google, se convertissait progressivement en une interface propice à l’échange : « Tu me dis quelque chose, j’essaie d’en comprendre le sens, puis je te propose une réponse. »
De là à basculer vers ce qu’aujourd’hui on appelle communément les interfaces conversationnelles … il n’y avait finalement qu’un pas…
Afficher une liste
Aujourd’hui, trente ans après ces lectures, vingt ans après cette émission radio, dix ans après ces recherches sur le dialogue homme machine, on prend conscience que l’IA a pris une place considérable dans nos quotidiens, et dans tous les domaines : imagerie médicale, assistance au diagnostic, traduction automatique, conduite assistée, création de contenus, analyse prédictive… et j’en passe.
Alors que penser de l’assistance à l’écriture de code… ou de la génération automatique d’algorithmes ?
N’est-on pas aujourd’hui à cette même lisière que lorsque Dreamweaver proposait d’assister les développeurs en produisant un code, certes naïf ou imparfait, mais qui permettait néanmoins de produire des contenus.
Où se trouve la frontière entre le choix et la décision, entre la perspective et le résultat, qui de l’un ou de l’autre doit primer ?
- Et pourquoi ne pas simplement questionner l’IA comme, à l’époque, l’on questionnait les livres, ces premiers livres qui nous aidaient à nous poser les bonnes questions… même s’ils ne nous apportaient pas forcément les bonnes réponses.
- Pourquoi ne pas écouter l’IA comme on écoutait ces émissions radios, ces débats, qui émettaient des réserves, qui nous prévenaient des éventuelles dérives, ou des chants de sirènes parfois trompeurs…
- Pourquoi ne pas dialoguer avec l’IA comme on apprendrait à dialoguer avec une nouvelle langue faite de nouvelles conventions, de nouveaux usages.
Explorer cette nouvelle terre faite d’inconnus, de dangers, d’émerveillements, de forces de propositions… Mais pour cela, il est important de continuer à rester curieux, à garder son esprit critique, et surtout sa faculté de décision. Qu’il s’agisse de comprendre ou transmettre l’interface applicative, qu’il s’agisse d’architecture et d’élaboration d’ergonomie, ou bien qu’il s’agisse de code rien n’est différent, pourvu que l’on sache de quoi il est question, de quoi il s’agit…
Produire le code est une chose, le comprendre en est une autre.
Ce qui importe avant tout, reste le service rendu, le destinataire auquel il s’adresse, la capacité de la solution à rester maintenable, évolutive et cohérente dans le temps. Que cette réponse ait été partiellement produite par un humain, un algorithme, ou une collaboration entre les deux, n’est peut-être pas la véritable question. La vraie interrogation porte sans doute davantage sur le cheminement qui nous y a conduit, les choix effectués, et notre capacité à conserver un regard critique et décisionnel sur le résultat obtenu.
Après tout, Dreamweaver un jour a proposé une palette flottante pour transformer une liste d’éléments en une balise HTML représentant cette liste. EMMET a un jour mis en place un pseudo langage pour écrire plus facilement et surtout plus rapidement cette même liste. Enfin, récemment, Vue.js est arrivé avec une nouvelle grammaire et a su encore plus rapidement restituer le même résultat.
Chaque époque n’a fait que déplacer un peu plus loin la frontière entre l’intention, l’écriture et l’automatisation.
Aujourd’hui, écrire un prompt qui interroge d’immenses clusters répartis dans des datacenters de la taille d’une ville, dispersés à travers le monde pour produire algorithmiquement cette même liste, parfois même à la manière d’un développeur référent, ne semble finalement être qu’une nouvelle étape de cette même continuité.
Qu’à cela ne tienne… car au fond… la problématique reste souvent la même. Organiser une information. Structurer un service. Rendre un contenu accessible… Afficher une liste.
Vers Gemini… et l’au-delà…
Les outils changent. Les couches d’abstraction se déplacent. Mais certaines intentions fondamentales traversent encore toutes ces évolutions. Alors, finalement, la manière dont cette liste aura été produite, importe peut-être moins que la capacité à comprendre le service qu’elle rend, les besoins auxquels elle répond, et la logique qui l’anime.
L’essentiel reste sans doute de continuer à forger notre savoir-faire, nourrir notre culture technique, et conserver notre capacité de décision face aux outils que nous utilisons.
Face à cette nouvelle page blanche faite d’un simple champ de texte, face à ce prompt, nous allons avancer caractère après caractère, en posant un scénario, un objectif, une intention. Petit à petit, quelque chose va émerger. Des incohérences apparaîtront, des blocages, des zones floues. Il faudra alors structurer, visualiser, reformuler, ajuster.
Car finalement, peu importe l’outil utilisé, tant que nous restons capables de comprendre les mécanismes à l’œuvre, de questionner les réponses produites, et de conserver notre capacité de décision et de validation.
