Bon. Respirez profondément. Ce qui vient est… surréaliste. Je viens d’ajouter une toute nouvelle fonctionnalité au logiciel que je développe (y compris l’interface utilisateur et les fonctionnalités), et ce juste en tapant quatre paragraphes d’instructions. J’ai des captures d’écran pour prouver cela. Pour le dire rapidement, je ne sais pas si nous vivons déjà dans le futur. Ou si nous venons de descendre dans un nouveau cercle des enfers (ou les deux).
Prenons un peu de recul. Jules de Google est le dernier en date d’une flopée de nouveaux agents de codage publiés la semaine dernière. Citons Codex de OpenAI, ou encore GitHub Copilot.
Tous ces agents de codage effectuent des opérations sur un dépôt GitHub. GitHub est un gigantesque centre de stockage, de gestion et de distribution de logiciels appartenant à Microsoft. Il est utilisé par la plupart des logiciels les plus importants au monde, en particulier côté open source.
Et Google a mis Jules à la disposition de tous, gratuitement. Cela signifie que j’ai pu m’y plonger et l’essayer. Et maintenant, j’ai la tête qui tourne.
Limites d’utilisation et mes deux premiers prompts
La version gratuite de Jules n’autorise que cinq requêtes par jour. Cela peut sembler peu. Mais en seulement deux requêtes, j’ai pu ajouter une nouvelle fonctionnalité à mon logiciel.
Ne sous-estimez donc pas ce que vous pouvez faire si vous réfléchissez à vos prompts avant d’agir.
Mes deux premiers prompts étaient provisoires. Je ne suis toujours pas à l’aise avec l’idée de lâcher une IA sur tout mon code en même temps. Alors j’ai joué la carte de la sécurité.
Fais moi la documentation que je n’ai jamais pris le temps de faire !
Mon premier prompt demandait à Jules de documenter ce que les développeurs de modules complémentaires pourraient utiliser pour ajouter des fonctionnalités à mon produit.
Je n’ai pas dit grand-chose à Jules sur ce que je voulais. Il m’a renvoyé des balises qu’il m’a recommandé d’insérer dans le fichier readme de mon code. Cela a fonctionné. Mais sans plus.
Capture d’écran par David Gewirtz/ZDNET
J’ai eu l’occasion de publier ce code dans une nouvelle branche GitHub. Mais je ne l’ai pas fait. Ce n’était qu’un test.
Suggère moi de nouvelles fonctionnalités
Ma deuxième demande consistait à demander à Jules de suggérer cinq nouvelles fonctionnalités. J’ai reçu une réponse qui semblait raisonnable. Cependant, j’ai réalisé que l’ouverture de ces capacités dans un produit de sécurité était tout simplement trop risquée pour que je la délègue à une IA. J’ai donc également ignoré ces changements.
C’est à ce moment-là que Jules a voulu faire une pause café. Il a cessé de fonctionner pendant environ… 90 minutes.
Capture d’écran par David Gewirtz/ZDNET
Cela m’a donné le temps de réfléchir. Ce que je voulais vraiment voir, c’était si Jules pouvait ajouter une réelle fonctionnalité à mon code et me faire gagner du temps.
Informations générales nécessaires avant d’aller de l’avant
My Private Site est un plugin de sécurité pour WordPress. Il fonctionne sur environ 20 000 sites actifs. Il place une boîte de dialogue de connexion devant les pages web du site. J’ai acquis le logiciel il y a une dizaine d’années auprès d’un codeur qui se faisait appeler « jonradio ». Et je l’ai maintenu et développé depuis.
Le plugin permet de contrôler l’accès au front d’un site web, c’est-à-dire aux pages que les visiteurs voient lorsqu’ils arrivent sur le site. Les propriétaires de sites contrôlent le plugin via une interface de tableau de bord.
J’ai décidé de tester Jules sur une fonctionnalité demandée par certains utilisateurs, à savoir cacher la barre d’administration aux utilisateurs connectés. La barre d’administration est la barre noire que WordPress place en haut d’une page web. Dans le cas de la capture d’écran ci-dessous, la barre d’administration noire est visible.
Capture d’écran par David Gewirtz/ZDNET
Cacher la barre d’administration aux utilisateurs connectés
Je voulais que Jules ajoute une option sur le tableau de bord pour cacher la barre d’administration aux utilisateurs connectés. L’idée est que si un utilisateur se connecte, la barre d’administration serait visible sur le back-end, mais les utilisateurs connectés qui naviguent sur le front-end du site n’auraient pas à voir cette affreuse barre.
Voici le tableau de bord original, avant l’ajout de la nouvelle fonctionnalité.
Capture d’écran par David Gewirtz/ZDNET
Il y a quelques années, j’ai complètement réécrit l’interface d’administration par rapport à ce qu’elle était lorsque j’ai acquis le plugin. L’ajout d’options à l’interface est simple. Mais cela prend du temps. Chaque option nécessite non seulement l’ajout d’un élément d’interface utilisateur, mais aussi la sauvegarde et le rappel des préférences lorsque le tableau de bord est affiché. Cela s’ajoute à toute logique de programme que la préférence contrôle.
Dans la pratique, j’ai constaté qu’il me fallait environ 2 à 3 heures pour ajouter un élément d’interface utilisateur de préférence, ainsi que les tâches administratives connexes. Ce n’est pas difficile. Mais il y a beaucoup de petits détails qui doivent être réglés. Cela prend du temps.
Cela devrait vous permettre de comprendre mon prochain test de Jules. Voici un peu d’anticipation : le premier test a échoué lamentablement. Le deuxième test a réussi de façon étonnante.
Instruire mon Jules
L’ajout d’une fonction pour cacher la barre d’administration n’est pas simple.
L’ajout de la nouvelle option au tableau de bord nécessite de la programmation à plusieurs endroits dans le code, et nécessite également une compréhension de la base de code globale.
Voici ce que j’ai dit à Jules
- Dans l’onglet Confidentialité du site de l’interface d’administration, ajoute une nouvelle case à cocher. Intitule la section « Barre d’administration » et la case à cocher elle-même « Masquer la barre d’administration ». [Place ceci dans le bloc RENDRE LE SITE PRIVÉ, juste en dessous de la case Activer la confidentialité de la connexion et avant le segment Mode de confidentialité du site].
J’ai indiqué à Jules où je voulais que l’IA place la nouvelle option. Lors de mon premier passage, j’ai fait une erreur et j’ai omis les détails entre crochets. Je n’ai pas dit à Jules exactement où je voulais qu’il place la nouvelle option. Il s’avère que cette omission a causé un gros échec. Une fois que j’ai ajouté la phrase entre crochets ci-dessus, la fonctionnalité a fonctionné.
- Veillez à enregistrer la sélection de cette case à cocher dans la variable des préférences du plugin lorsque le bouton Enregistrer l’état de la confidentialité est coché.
Cela permet à Jules de savoir qu’il existe une structure de données de préférences et de la mettre à jour lorsque l’utilisateur effectue un changement. Il est important de noter que si je n’avais pas compris le code sous-jacent, je n’aurais pas donné d’instructions à Jules à ce sujet et le code n’aurait pas fonctionné.
- Afficher l’état coché ou non coché approprié lorsque l’onglet Confidentialité du site est affiché.
Cela indique à l’IA que je veux que l’interface soit mise à jour pour correspondre à ce que la variable de préférence spécifie.
- En fonction de la variable de préférence créée en (2), ajouter du code pour masquer ou afficher la barre d’administration de WordPress. Si l’option Cacher la barre d’administration est cochée, la barre d’administration ne doit pas être visible pour les utilisateurs de WordPress connectés. Si l’option Cacher la barre d’administration n’est pas cochée, la barre d’administration doit être visible pour les utilisateurs frontaux connectés. Les utilisateurs du back-end connectés à l’interface d’administration doivent toujours être en mesure de voir la barre d’administration.
Ceci décrit la logique métier que la nouvelle préférence doit contrôler. Elle nécessite que l’IA sache comment cacher ou afficher la barre d’administration (un appel à l’API de WordPress est utilisé), et que l’IA sache où placer le code dans mon plugin pour activer ou désactiver cette fonctionnalité.
Et avec cela, Jules a été formé à ce que je voulais faire.
Jules plonge dans mon code
J’ai transmis mes prompts à Jules. Et j’ai obtenu en retour un plan d’action. Prêtez attention au bouton Approuver le plan?.
Capture d’écran par David Gewirtz/ZDNET
Je n’ai même pas eu le temps de lire le plan avant que Jules ne décide de l’approuver de lui-même. C’est ce qu’il a fait après chaque plan qu’il a présenté. Une IA qui n’attend pas la permission me fait dresser les cheveux sur la tête. Je vous le dis.
Capture d’écran par David Gewirtz/ZDNET
Voici une partie du code que Jules a écrit. Le vert ombré est le nouveau code. Je ne suis pas emballé par l’agencement des couleurs, mais je suis sûr qu’il sera possible de le modifier au fil du temps.
Jules a compris mes conventions de dénomination des variables et l’architecture de mon code
Ce qui est plus important, c’est le fait que Jules a compris mes conventions de dénomination des variables et l’architecture de mon code et qu’il s’y est plongé. Voici la nouvelle option, rendue en code.
Capture d’écran par David Gewirtz/ZDNET
À la fin du projet, Jules avait écrit toutes les modifications de code qu’il avait prévues à l’origine, ainsi que du code de test. Je n’utilise pas de tests standardisés. J’aurais dit à Jules de ne pas procéder comme il l’avait prévu, mais il ne m’a jamais laissé le temps d’approuver ou de modifier son plan initial. Malgré tout, cela a fonctionné.
Capture d’écran par David Gewirtz/ZDNET
J’ai appuyé sur le bouton Publier la branche, ce qui a amené GitHub à créer une nouvelle branche, distincte de mon dépôt principal. Jules a ensuite publié ses modifications dans cette branche.
Capture d’écran par David Gewirtz/ZDNET
C’est ainsi que les contributeurs de grands projets peuvent travailler sans provoquer de chaos dans la branche de code principale.
Jusqu’à présent, je pouvais consulter le code. Mais je ne pouvais pas l’exécuter. Mais en poussant le code vers une branche, Jules et GitHub m’ont permis de reproduire les changements en toute sécurité sur mon ordinateur pour les tester. Si je n’aimais pas les changements, j’aurais pu revenir à la branche principale. Et il n’y aurait pas eu de mal, ni de faute. Mais comme j’aimais les changements, je suis passé à l’étape suivante.
Faire le tour du code en 8 clics
Une fois que j’ai ramené la branche sur ma machine de développement, j’ai pu la tester. Voici le nouveau tableau de bord avec la fonctionnalité Hide Admin Menu.
Capture d’écran par David Gewirtz/ZDNET
J’ai essayé d’activer et de désactiver la fonction et de m’assurer que les paramètres restaient inchangés. C’est le cas. J’ai également essayé d’autres fonctionnalités du plugin pour m’assurer que rien d’autre ne s’était cassé. J’étais à peu près sûr que ce n’était pas le cas, car j’ai revu tous les changements avant d’approuver la branche. Mais tout de même. Tester est une bonne chose à faire.
Je me suis ensuite connecté au site web de test. Comme vous pouvez le voir, il n’y a pas de barre d’administration.
Capture d’écran par David Gewirtz/ZDNET
Déployer les changements, à la fois sur GitHub et sur le dépôt principal de WordPress
À ce stade, l’IA n’a plus aucun contrôle sur le processus. Il était simplement temps de déployer les changements, à la fois sur GitHub et sur le dépôt principal de WordPress. Tout d’abord, j’ai utilisé GitHub Desktop pour fusionner le code de la branche dans la branche principale sur ma machine de développement.
Capture d’écran par David Gewirtz/ZDNET
J’ai changé « Hide Admin Menu » en « Hide admin menu » dans la branche principale de mon code. J’ai repoussé cette branche (la branche principale complète sur ma machine locale) sur le cloud GitHub.
Capture d’écran par David Gewirtz/ZDNET
Ensuite, parce que je n’aime pas que des branches aléatoires traînent une fois qu’elles ont été incorporées dans la version de distribution, j’ai supprimé la nouvelle branche sur mon ordinateur.
Capture d’écran par David Gewirtz/ZDNET
J’ai également supprimé la nouvelle branche du service GitHub.
Capture d’écran de David Gewirtz/ZDNET
Enfin, j’ai empaqueté le nouveau code. J’ai ajouté une modification au fichier readme pour décrire la nouvelle fonctionnalité et mettre à jour le numéro de version du code. Ensuite, je l’ai poussé en utilisant SVN (le système de contrôle du code source utilisé par la communauté WordPress) vers le dépôt de plugins WordPress.
Voyage au centre du code
Jules est une version bêta pour l’instant. Il s’est parfois bloqué. Certains écrans n’ont pas été mis à jour. Il a décidé de se déconnecter pendant 90 minutes.
Le fait que Jules (et probablement OpenAI Codex et GitHub Copilot Coding Agent) puisse gérer un dépôt entier de code à travers un tas de fichiers est important. C’est un niveau de compréhension et d’intégration beaucoup plus profond que ce que nous avons vu jusqu’à présent. Même il y a six mois.
La vitesse à laquelle il peut modifier une base de code entière est terrifiante. Les dégâts qu’il peut causer sont extraordinaires. Il va allègrement passer en revue et modifier tout ce qui se trouve dans votre base de code. Et si vous spécifiez une erreur, et que vous poussez en prod ou fusionnez, vous aurez un gâchis intégral sur les bras.
La fin des développeurs ? Loin s’en faut
Il existe une profonde inégalité entre la vitesse à laquelle il peut modifier le code et le temps qu’il faudra à un humain pour examiner ces changements. Travailler à cette échelle nécessitera d’excellents tests unitaires. Même des outils comme le mien, qui ne se prêtent pas à des tests unitaires complets, nécessiteront une sorte de validation automatisée pour éviter les erreurs robotisées à grande échelle.
Certes, ceux qui s’inquiètent pour les emplois des programmeurs peuvent se faire du mouron. Mais pas de la manière dont la plupart des gens le pensent. Il est absolument, totalement, nécessaire que des codeurs expérimentés examinent et guident ces agents. Lorsque j’ai omis une instruction essentielle, l’agent a joyeusement bloqué mon site.
Comme c’est moi qui avais écrit le code au départ, je savais ce qu’il fallait faire. Mais il aurait été très très difficile pour quelqu’un d’autre de comprendre ce qui avait été omis et comment le réparer. Pour cela, il aurait fallu se familiariser avec toutes les nuances cachées de l’architecture entière du code.
Mais comment va t-on former les développeurs junior ?
Les emplois susceptibles d’être détruits sont ceux des développeurs juniors. Jules fait facilement du travail de développeur junior. Avec des outils comme Jules, Codex ou Copilot, qui coûtent quelques centaines de dollars par mois au maximum, il sera difficile pour la direction d’accepter de payer des salaires à six chiffres ou plus pour des programmeurs de niveau intermédiaire ou junior. Même l’externalisation et la délocalisation ne sont pas aussi bon marché que l’utilisation d’un agent d’intelligence artificielle pour effectuer le codage de maintenance.
Et la vrai question c’est donc comment formerons-nous les développeurs junior à devenir des experts dont nous aurons besoin à l’avenir ?
Capture d’écran par David Gewirtz/ZDNET
Quant à moi, en moins de 10 minutes, j’ai mis au point une nouvelle fonctionnalité demandée par les utilisateurs. Pendant que j’écrivais un autre article, j’ai transmis le message à Jules. Je suis retourné travailler sur l’article et j’ai pris des nouvelles de Jules lorsqu’il a terminé. J’ai vérifié le code, je l’ai transféré sur mon ordinateur et j’ai lancé la version.
J’ai accompli une demi-journée de travail… en moins d’une demi-heure
Il m’a fallu plus de temps pour télécharger le code dans le dépôt de WordPress que pour ajouter l’ensemble de la nouvelle fonctionnalité. Au final, pour cette catégorie de fonctionnalité, j’ai accompli une demi-journée de travail… en moins d’une demi-heure.
Et au cours des deux dernières heures, 2 500 sites ont téléchargé et installé la nouvelle fonctionnalité. Ce chiffre devrait dépasser les 10 000. Sans Jules, ces utilisateurs auraient probablement dû attendre des mois pour bénéficier de cette nouvelle fonctionnalité. Mais avec Jules, cela n’a demandé qu’un effort minime.
Ces outils vont obliger les programmeurs à repenser le processus de développement de logiciels. Et une véritable intelligence humaine sera nécessaire pour comprendre comment y faire face.