mardi 20 octobre 2026

Une journée de développement presque sans coder

Aujourd’hui, j’ai vécu une journée de développement assez particulière : je n’ai presque pas écrit de code moi-même, et pourtant j’ai rarement eu l’impression d’être aussi productif.

On était, comme on dit, sua coche.

Depuis quelque temps, je travaille sur mon application personnelle avec l’aide de Codex. Au début, comme bien des développeurs, j’avais tendance à lui confier des demandes assez larges. Le résultat pouvait être intéressant, mais il fallait ensuite comprendre tout ce qui avait changé, corriger certains choix et ramener la solution vers ce que j’avais réellement en tête.

Aujourd’hui, notre façon de travailler était beaucoup plus naturelle. J’ai mieux découpé mes demandes, l’IA a travaillé dans des limites plus précises et nous avons avancé par petites étapes faciles à vérifier.

Une demande à la fois

La différence vient en grande partie du découpage.

Au lieu de demander toute une fonctionnalité en une seule fois, je précise d’abord le prochain résultat attendu. L’IA inspecte le code existant, m’explique ce qu’elle propose et attend mon signal avant de modifier quoi que ce soit. J’utilise simplement le mot GO lorsque la proposition me convient.

Le rythme ressemble à ceci :

  1. je décris un besoin limité;
  2. l’IA examine ce qui existe déjà;
  3. elle propose une modification;
  4. nous discutons au besoin du comportement ou de l’interface;
  5. je donne le GO;
  6. elle applique et vérifie le changement;
  7. je teste le résultat dans l’application.

Cette façon de procéder réduit beaucoup les surprises. Chaque intervention est assez petite pour que je puisse en comprendre l’intention et constater immédiatement si elle correspond à mon besoin.

Pouvoir changer d’idée fait partie du travail

La meilleure illustration de cette méthode aujourd’hui concernait la consultation des comptes inactifs.

Notre première solution permettait de les afficher à l’aide d’une option ajoutée dans l’interface principale. Elle fonctionnait. Malgré cela, quelque chose me dérangeait : les comptes inactifs sont consultés exceptionnellement, alors pourquoi rendre cette option visible en permanence?

Nous avons donc arrêté de penser seulement en termes de code pour revenir au besoin réel.

L’application possédait déjà une page de gestion des comptes. Il devenait plus logique d’y ajouter un accès consacré aux comptes inactifs, dans un mode de consultation adapté. La première solution a été retirée, la tâche a été reformulée et nous sommes repartis avec une approche plus simple pour l’utilisateur.

C’est un aspect de la collaboration que j’apprécie de plus en plus. L’IA peut proposer et exécuter rapidement, mais je reste libre de dire : « Ça fonctionne, mais ce n’est probablement pas la bonne expérience. »

Du code fonctionnel n’est pas nécessairement la meilleure solution.

L’IA comme partenaire de réflexion

La journée ne s’est pas limitée à donner des commandes à une machine.

Nous avons discuté de l’emplacement d’un bouton, de la pertinence de modifier un compte inactif, du comportement attendu d’une page spécialisée et de la meilleure façon de réutiliser ce qui existait déjà. Nous avons aussi repéré un rafraîchissement inutile, compris sa cause et corrigé le comportement sans élargir inutilement la portée du changement.

Dans ce contexte, l’IA agit moins comme un générateur de code que comme un collègue disponible pour examiner une idée, parcourir le projet et transformer une décision en modification concrète.

Elle apporte sa vitesse pour chercher, comparer et écrire. J’apporte la connaissance de l’application, mes préférences, le contexte fonctionnel et surtout mon jugement sur le résultat.

Cette répartition devient particulièrement efficace lorsque je formule clairement ce que je veux et que je limite chaque intervention à une étape précise.

Presque pas de code, mais beaucoup de développement

Il serait facile de croire qu’une journée où j’écris peu de code est une journée où je développe moins. Mon expérience d’aujourd’hui me montre plutôt le contraire.

J’ai défini des comportements, pris des décisions d’interface, corrigé une orientation, validé plusieurs résultats et gardé la documentation du projet à jour. Le code est une partie du développement, mais il n’en représente pas toute la valeur.

La vraie responsabilité demeure de construire la bonne chose, de comprendre les conséquences des choix et de décider si le résultat mérite de rester.

L’IA peut écrire une grande partie des lignes. Elle ne connaît toutefois pas spontanément mes utilisateurs, l’histoire du projet ni les compromis que je suis prêt à accepter. Plus je lui donne des demandes ciblées, plus elle devient efficace sans prendre la place de ces décisions.

Une méthode qui se construit

Je ne crois pas avoir trouvé une formule définitive. Notre façon de travailler continue d’évoluer chaque fois qu’une demande est trop large, qu’une proposition manque de contexte ou qu’une meilleure idée apparaît en cours de route.

Je remarque néanmoins quelques habitudes qui font une vraie différence :

  • découper le travail en résultats courts et vérifiables;
  • demander une analyse avant les changements;
  • discuter du comportement avant de parler de l’implantation;
  • tester après chaque étape;
  • accepter de retirer une solution qui fonctionne si elle répond mal au besoin;
  • conserver une trace des décisions et du travail réalisé.

Cette méthode me permet aussi d’apprendre. Je pose encore des questions sur le code produit, les types utilisés ou les choix proposés. Je ne veux pas seulement obtenir un résultat : je veux rester capable de comprendre et de faire évoluer mon application.

Une bonne journée d’équipe

Ce soir, j’ai l’impression que nous avons franchi une étape dans notre collaboration.

Je deviens meilleur pour expliquer ce que je veux et pour diviser le travail. De son côté, l’IA intervient dans un cadre de plus en plus clair. Ses modifications sont plus ciblées, plus faciles à valider et mieux alignées sur le projet.

Le plus intéressant n’est donc pas d’avoir presque cessé d’écrire du code pendant une journée. C’est d’avoir consacré mon énergie aux endroits où mon expérience compte le plus, tout en laissant l’outil accélérer l’exécution.

Aujourd’hui, j’ai peu codé. J’ai quand même pleinement développé mon application.

Et oui, on était vraiment sua coche.

1 commentaire:

  1. Interessant! Et elle répond assez rapidement? Cuánto tarda en responder normalmente?

    RépondreSupprimer

Une journée de développement presque sans coder

Aujourd’hui, j’ai vécu une journée de développement assez particulière : je n’ai presque pas écrit de code moi-même, et pourtant j’ai rareme...