Il y a quelques jours, j’ai créé une première version de mon site en utilisant principalement des assistants de programmation comme Codex et CoWork. Le site fonctionnait, la direction générale était en place et j’aurais très bien pu continuer à le modifier progressivement. J’ai pourtant décidé de le reprendre presque entièrement quelques jours plus tard.
Ce n’était pas parce que la première version était mauvaise ou inutilisable. J’avais simplement eu de nouvelles idées entre-temps, et je me suis rendu compte qu’il serait probablement plus rapide de repartir sur une nouvelle base que d’essayer d’adapter ce qui existait déjà. C’est surtout ce point qui m’a marqué.
La vitesse de développement est évidemment impressionnante, mais le changement le plus intéressant est peut-être ailleurs. Quand refaire un projet devient presque aussi simple que le corriger , notre rapport au logiciel commence à évoluer assez sérieusement.
Refaire le site plutôt que modifier l’ancien
Il n’y a encore pas si longtemps, la création d’un site de ce type aurait probablement demandé plusieurs semaines de travail avec un prestataire. Il aurait fallu définir le projet, préparer les maquettes, expliquer les différentes interactions, attendre une première version, transmettre des corrections, puis recommencer plusieurs fois jusqu’à obtenir quelque chose de suffisamment proche de ce que j’avais en tête. Chaque changement important aurait aussi posé la question du coût.
Une fois qu’une structure est validée et développée, on hésite forcément davantage avant de demander de la reprendre complètement. Dans mon cas, j’ai pu créer une première version du site, l’utiliser comme base de réflexion, voir ce qui fonctionnait et ce qui correspondait moins bien à ce que je voulais faire, puis recommencer lorsque j’ai eu une meilleure idée. La première version n’était pas vraiment du travail perdu.
Elle m’avait permis de comprendre le projet, de tester une organisation et de préciser ce que je voulais pour la suite. En parallèle, j’ai commencé à intégrer au site plusieurs applications et petits jeux, eux aussi développés entièrement et trés rapidement avec d'autres IA ( cowork, GLM, Gemini… ) Ce genre de décision devient beaucoup plus facile lorsqu’elle ne représente plus plusieurs jours ou plusieurs semaines de développement supplémentaire.
Des progrès visibles d’un projet à l’autre
J’utilise régulièrement plusieurs modèles et plusieurs outils de programmation assistée, et leur progression devient assez difficile à ignorer . En un an, la qualité du code généré a évolué, mais ce n’est qu’une partie du changement. Les outils comprennent mieux les demandes, produisent des interfaces plus cohérentes, font moins d’erreurs et arrivent plus facilement à corriger un projet existant sans casser ce qui fonctionne déjà.
Les résultats graphiques ont aussi beaucoup progressé. Il fallait auparavant guider très précisément les modèles pour éviter d’obtenir des interfaces assez génériques. C’est toujours utile de donner une direction claire, évidemment, mais certains outils sont maintenant capables de proposer rapidement une première base visuelle exploitable, avec une hiérarchie, des espacements et des interactions qui tiennent déjà assez bien la route.
Cette progression me rappelle ce qui s’est passé avec la génération d’images, puis avec la vidéo. Les premières versions permettaient surtout de comprendre le principe. Ensuite, assez rapidement, les outils ont commencé à devenir réellement utilisables dans des projets.
Le code semble suivre une trajectoire assez proche, même si les conséquences sont différentes puisqu’un logiciel ne se limite pas à son apparence. Il doit fonctionner , conserver des données, gérer des erreurs et rester compréhensible lorsqu’on revient dessus quelques semaines plus tard. Pour le moment, cela demande encore de vérifier ce qui est produit et de corriger régulièrement les propositions.
Cela dit, la vitesse à laquelle les problèmes sont résolus change déjà beaucoup la manière de travailler .
Tous les modèles ne travaillent pas de la même manière
L’un des aspects les plus intéressants, quand on utilise quotidiennement plusieurs modèles, est qu’ils ont encore des comportements très différents. Certains comprennent particulièrement bien une demande graphique et arrivent rapidement à construire une interface proche de celle que j’avais imaginée. D’autres sont plus à l’aise avec la structure générale d’une application, l’organisation des fichiers ou la manière dont les différentes fonctions doivent communiquer .
Il y a aussi des modèles qui se montrent très efficaces pour reprendre un code existant, repérer l’origine d’un problème et proposer une correction assez propre, alors qu’ils sont moins convaincants lorsqu’il faut concevoir le projet dès le départ. La hiérarchie n’est d’ailleurs pas toujours celle que l’on pourrait imaginer en regardant simplement la date de sortie ou les résultats généraux annoncés pour chaque modèle. Sur certaines tâches très précises, un modèle que l’on pourrait croire dépassé peut encore produire de meilleurs résultats qu’un outil plus récent.
Quelques semaines plus tard, cette situation peut à nouveau changer . Dans la pratique, le choix du modèle devient donc une partie du travail. J’utilise rarement un seul outil pour tout faire.
Je peux commencer un projet avec celui qui comprend le mieux la structure générale, passer sur un autre pour travailler l’interface, puis revenir vers un troisième lorsqu’il faut corriger un problème particulier . Cette manière de travailler reste encore un peu instable, puisque les performances évoluent vite et que les réponses peuvent parfois être imprévisibles. Pour le moment, elle permet néanmoins d’avancer beaucoup plus rapidement qu’en essayant de forcer un seul modèle à réaliser toutes les étapes.
Le travail commence de plus en plus avant le code
Le fait de pouvoir générer du code rapidement ne supprime pas la réflexion autour du projet. Dans mon cas, j’ai même l’impression que cette réflexion devient plus importante. Lorsque le développement représentait l’essentiel du temps et du coût, une grande partie de l’attention était naturellement consacrée à la faisabilité technique.
Il fallait savoir si une fonction était réaliste, combien de temps elle allait demander et si elle justifiait réellement le travail nécessaire. Aujourd’hui, on peut produire une première version beaucoup plus tôt. Le problème se déplace donc vers la définition de ce que l’on veut réellement construire.
Avant de commencer , il faut toujours comprendre le besoin, les personnes qui vont utiliser l’outil, l’organisation des menus, les écrans nécessaires, les interactions et les priorités. Une IA peut proposer beaucoup de choses, mais elle ne connaît pas naturellement l’objectif du projet, le public auquel il s’adresse ni les raisons pour lesquelles une fonction est plus importante qu’une autre. Elle peut également produire très vite une interface parfaitement fonctionnelle qui ne répond pas vraiment au problème de départ.
Le rôle humain se déplace progressivement vers la conception, la direction artistique, les choix et les corrections. Le code reste important, mais il n’est plus forcément l’obstacle principal. Ma manière de développer commence donc à se structurer assez naturellement.
Je travaille d’abord l’idée, puis l’organisation générale du projet. Je définis les fonctions principales, les écrans et les interactions, avant de choisir l’outil qui me semble le plus adapté pour créer une première version. Ensuite, je corrige au fur et à mesure, en regardant le résultat plutôt qu’en essayant de tout prévoir parfaitement avant de commencer .
Cette méthode reste très expérimentale, mais elle fonctionne déjà assez bien pour des projets de petite ou moyenne taille.
Créer un logiciel pour un besoin précis
Cette expérience m’a surtout amené à réfléchir à la durée de vie des logiciels que nous utilisons. Aujourd’hui, lorsqu’on a besoin d’un outil, même très simple, le réflexe consiste généralement à chercher s’il existe déjà. On compare plusieurs solutions, on en télécharge une, on l’installe, puis on apprend à l’utiliser .
Il faut parfois créer un compte, accepter un abonnement ou adapter sa manière de travailler à l’organisation choisie par l’éditeur . Pour de nombreux besoins, cela restera probablement la solution la plus logique. Il serait assez absurde de recréer seul un logiciel complexe qui existe déjà, qui est maintenu par une équipe et qui répond correctement au problème.
En revanche, pour des outils très spécifiques, la situation pourrait évoluer rapidement. On peut imaginer créer une calculatrice adaptée à un métier , un convertisseur particulier , un outil d’analyse, un système de classement ou une petite application qui automatise une tâche répétitive. Un architecte pourrait produire un outil de mesure correspondant à sa manière de travailler .
Un artisan pourrait créer un système de devis limité à son activité. Une personne travaillant dans la location immobilière pourrait fabriquer une interface qui organise exactement les informations dont elle a besoin. Dans mes propres projets, cela pourrait être un storyboard, un générateur lié au speed painting, un petit jeu pédagogique ou une application conçue pour une formation précise.
Ces outils ne seraient pas nécessairement destinés à devenir des produits complets, vendus et maintenus pendant plusieurs années. Ils pourraient être créés pour répondre à un besoin ponctuel, utilisés pendant quelques jours ou quelques mois, puis abandonnés lorsqu’ils ne sont plus utiles. Le terme de logiciel jetable peut sembler assez négatif, notamment parce qu’il évoque quelque chose de mal conçu ou de peu fiable.
Dans l’idée, il s’agit plutôt d’un outil dont la durée de vie correspond au besoin réel. On ne cherche pas forcément à construire une solution universelle. On crée simplement le logiciel nécessaire à un moment précis.
Une autonomie qui ne concerne pas uniquement les développeurs
Cette évolution ne concerne pas seulement les personnes qui travaillent déjà dans le développement. Un enseignant peut créer un outil pour expliquer une notion à ses élèves. Un designer peut construire une application qui automatise une partie très particulière de son workflow.
Un étudiant peut produire une interface pour classer ou analyser les données de son mémoire. Un chercheur peut adapter un outil à une expérience sans attendre qu’un logiciel commercial ajoute la fonction dont il a besoin. Le résultat ne sera pas toujours parfait, et tous ces outils ne pourront pas être utilisés dans des contextes sensibles ou par un grand nombre de personnes sans vérification supplémentaire.
Il existe une différence importante entre une petite application personnelle et un logiciel qui doit être sécurisé, maintenu et utilisé par des milliers de personnes. Malgré cela, une nouvelle forme d’autonomie devient déjà possible. Cette situation ressemble assez fortement à ce qui s’est produit avec l’image générée par IA.
Beaucoup de personnes avaient peut-être depuis longtemps l’idée d’illustrer un livre, de produire une bande dessinée, de créer un court métrage ou simplement de raconter une histoire en images, sans avoir les compétences techniques nécessaires pour le faire seules. Les outils de génération n’ont pas remplacé tout le travail créatif, mais ils ont permis à davantage de personnes de passer d’une idée à une première réalisation. Le code pourrait suivre la même trajectoire.
Des personnes qui réfléchissent depuis des années à un outil particulier pourront commencer à le fabriquer elles-mêmes, même si elles ne se considèrent pas comme développeuses. Elles devront toujours apprendre à expliquer leur besoin, tester les résultats et repérer les erreurs, mais la barrière technique devient progressivement moins importante.
Ce que cela peut changer pour les métiers du logiciel
Il est encore difficile de savoir jusqu’où cette évolution ira. Pour le moment, les développeurs, les web designers et les personnes spécialisées dans l’automatisation conservent une expertise importante, notamment lorsqu’un projet doit gérer beaucoup d’utilisateurs, des données sensibles ou une architecture complexe. La compréhension des besoins, l’ergonomie, la sécurité, l’expérience utilisateur et la maintenance restent également des sujets qui ne peuvent pas être résolus uniquement en demandant à un modèle de générer du code.
Cela dit, une partie du travail technique peut déjà être réalisée beaucoup plus rapidement, et il serait difficile d’imaginer que cela n’aura aucun impact sur la manière dont ces métiers sont organisés et vendus. La valeur pourrait se déplacer davantage vers la capacité à comprendre un projet, à structurer une solution, à prendre de bonnes décisions et à vérifier ce qui a été produit. Pour les petits sites et les applications assez simples, la frontière entre le concepteur et le développeur devient déjà moins nette.
Une personne qui connaît bien son métier et qui sait précisément ce qu’elle veut peut maintenant produire seule une première version qui aurait auparavant demandé l’intervention de plusieurs profils. Sur des projets de plus grande ampleur , l’expertise technique restera probablement nécessaire beaucoup plus longtemps, même si les équipes utiliseront elles aussi ces outils pour avancer plus vite. Il existe également des limites plus générales.
Les assistants peuvent produire du code mal sécurisé, mal comprendre une instruction ou modifier une partie du projet que l’on ne voulait pas toucher . Les mêmes outils peuvent aussi servir à développer des usages malveillants, ce qui pose évidemment d’autres problèmes. Ces réserves sont importantes, mais elles ne changent pas vraiment la tendance que j’observe dans mes propres projets.
Je savais déjà que les assistants de programmation pouvaient créer un site ou une petite application. Ce que je n’avais pas complètement anticipé, c’était la facilité avec laquelle j’allais pouvoir reprendre ces projets, les modifier et parfois les refaire entièrement dès qu’une meilleure idée apparaissait. C’est probablement cette possibilité qui aura le plus d’impact sur ma manière de travailler .
Le logiciel risque de devenir moins précieux en lui-même, simplement parce qu’il sera plus facile d’en produire un nouveau. Ce qui comptera davantage sera l’idée, la compréhension du besoin et la manière dont l’outil s’intègre dans un projet réel. À terme, créer une petite application pourrait devenir une activité assez courante, presque au même titre que préparer un document, construire un tableau ou générer une image pour illustrer une idée.
Pour le moment, j’en suis encore à tester cette manière de travailler , mais le fait d’avoir préféré refaire mon site quelques jours après sa création montre déjà que quelque chose a changé.