L'Art de Construire avec l'IA : Une Expérience de Développement en Pleine Mutation

Personne ne sait comment Construire avec l'IA La semaine dernière, j’ai lancé une application appelée Protocollie. Elle a été construite en quatre jours, utilisant des langages que je ne maîtrise pas, sans même toucher directement le code. Les gens me demandent souvent : « Comment avez-vous fait ça ? » Mais la vérité est que personne ne peut prédire avec certitude que cette méthode fonctionnera à nouveau exactement de la même façon. Nous sommes tous en train d’inventer la roue. Il y a un moment avec chaque nouvelle technologie où tout le monde prétend savoir ce qu’il fait. Nous avons peut-être dépassé ce moment, ou peut-être que nous n’y sommes pas encore arrivés. Quoi qu'il en soit, nous nous trouvons dans ce champ fertile où personne ne peut feindre l'expertise, car tout change constamment sous nos yeux. Récemment, je me suis interrogé sur la notion d'expertise. Combien de temps faut-il pour devenir un expert ? Malcolm Gladwell affirmait qu’il fallait 10 000 heures, mais il parlait de compétences comme le violon ou l'échecs, où les règles ne changent pas toutes les deux semaines. Lorsque le programmeur en IA le plus expérimenté n’a que deux ans de pratique, alors nous sommes tous des débutants. Et probablement, nous le resterons toujours, au rythme actuel des avancées technologiques. Ce que j’appelle un "système" n'est pas tant planifié que le fruit d'une accumulation. Comme quand un bureau commence à collecter des papiers jusqu'à ce qu’apparaisse un "système de classement". Protocollie a commencé avec un seul document parce que j'avais tendance à oublier ce que j’avais expliqué à Claude, l'IA avec qui j'ai travaillé, sur l'architecture. Puis deux documents, car je me lassais de résoudre les mêmes problèmes. Ensuite trois, car j’ai remarqué que mon workflow se répétait. Enfin, quatre documents, car les histoires nécessitaient un endroit où vivre. Je ne suis pas sûr que quatre soit un chiffre optimal, c'est juste où j’ai arrêté. Le premier dimanche où j’ai construit Protocollie, j’ai découvert un nouveau mode de travail. Je m'installais dans mon bureau, vérifiais ce que Claude avait construit, effectuais de rapides tests. Si tout fonctionnait, je faisais un commit et un push, puis donnais la prochaine instruction, genre "Construis maintenant l'interface de connexion au serveur", et reprenais ma vie quotidienne. Je préparais le petit déjeuner, Claude codait. Je jouais avec mon fils, Claude codait encore. Je regardais la télévision, et Claude continuait de coder. Toutes les heures, je revenais quelques minutes pour tester et donner un retour rapide. En fin de journée, j’avais passé environ 90 minutes à faire des tâches véritablement "de travail" : prise de décision, tests, corrections. Le reste du temps, j’en profitais pour vivre tranquillement pendant que le logiciel évoluait en arrière-plan. Cette méthode introduit une étrange dilatation temporelle. Tu donnes une instruction, tu vis ta vie, tu reviens et trouves dix mille lignes de code. Tu passes cinq minutes à lire, une minute à donner des feedbacks, et voilà que dix mille lignes supplémentaires apparaissent pendant que tu cuisines ton déjeuner. Le rapport entre l'input et l'output, entre l'effort et le résultat, entre le temps et la progression, brise tous les modèles mentaux que j’avais de ce que devrait être le travail. Parfois, je me sens coupable. Comme si je trichais. Comme si quelqu'un sur Hacker News allait commenter : "Excusez-moi, vous ne pouvez pas construire un logiciel aussi rapidement, et certainement pas pendant que vous faites des crêpes, veuillez revenir à votre lutte habituelle." J’ai récemment comparé cette phase du développement en IA à "jeter des spaghettis contre les murs". On m'a corrigé : "Vous voulez dire 'et voir ce quiadhère' ?" Non, je veux dire lancer des spaghettis contre les murs. Que ça adhère ou non est secondaire. Ce qui compte, c’est le lancé lui-même. Chaque bizarre procédure, chaque essai infructueux, chaque moment où quelque chose fonctionne alors qu’on pensait le contraire, ce sont autant de points de données dans une grande expérience que nous menons collectivement sans hypothèse claire. Mon système basé sur quatre documents ? Des spaghettis qui ont formé un motif que j’ai pu reconnaître. Demain, ils peuvent glisser du mur. Cela n’a pas d'importance. J'en lancerai d'autres. Je code depuis assez longtemps pour avoir vécu des époques où nous taillions des tables HTML à la main, où CSS n’était qu'une suggestion, et où JavaScript servait principalement aux effets de souris. Chaque période, nous avons abstrait les travaux de la précédente. Du langage assembleur vers C, de C vers Java, de Java à Ruby, jusqu’à aujourd’hui où je décris simplement ce que je veux et ça apparaît. Mais ce n’est pas seulement une nouvelle couche d’abstraction. C’est quelque chose d’étrange, d’inclassable. Lorsque j’ai construit Protocollie, je n’étais ni un programmeur classique, ni non-programmeur. Je ne sais pas comment qualifier ce rôle. Nous n’avons pas encore de mot pour ça. Les compétences nécessaires ne sont pas seulement la syntaxe, les algorithmes, ou même la conception de systèmes. C'est plus comme une forme de “désir cohérent” ou d'"imagination précise" ou de “souhait structuré”. En regardant mes documents, je réalise qu'ils ne concernent pas vraiment le code ; ils traitent de la mémoire et de l'oubli, de ce qui importe assez pour être préservé et de ce qui peut être régénéré. L’Architecture Overview n’est pas vraiment une architecture : “Que voudrais-je savoir si j’étais amnésique ?” Les Technical Considerations ne sont pas vraiment des instructions : “Quels sont les points de frustration que je ne veux pas répéter ?” Le Workflow Process ne ressemble pas vraiment à un processus : “Quelles sont les structures qui emerged et que je ne veux pas perdre ?” La Story Breakdown n’est pas vraiment un plan : “Comment fait-on pour progresser lorsque tout recommence à zéro ?” Peut-être que toutes nos documentations ne sont que des messages adressés à des versions futures de nous-mêmes, perdues et confuses. Nous sommes tous redevenus des développeurs juniors, mais pas dans le sens traditionnel où l'on attend de devenir senior après des années d'expérience. Nous sommes juniors de manière permanente, car la technologie évolue plus rapidement que l'expertise peut s’accumuler. C’est comme être un surfeur professionnel sur un océan dont les lois physiques changent constamment. Juste au moment où tu crois comprendre les vagues, elles commencent à bouger latéralement, à revenir en arrière, ou à se transformer en oiseaux. Cette incertitude était autrefois source d'anxiété. Maintenant, elle donne lieu à une sorte de magie. Chaque développeur est simultanément un expert (de sa propre méthode chaotique) et un débutant absolu (devant ce qui vient ensuite). En quatre jours, ce qui prenait des mois peut être réalisé. Et la compétence principale est de pouvoir expliquer ce que tu veux à une IA qui tape plus vite que tu ne peux penser. Mon système basé sur quatre documents n’est pas une recommandation. C'est juste une autre donnée dans l’expérience collective que nous menons tous. Un fossile de mon processus de développement de la semaine dernière. Déjà obsolète, déjà nostalgique. C'est ce qui rend ce moment électrique. Nous construisons tous des châteaux de sable à marée basse, sachant que l'eau reviendra. Les châteaux de sable sont nos logiciels, la marée est le progrès, et nous passons un moment incroyable. Demain, quelqu’un découvrira un système basé sur trois documents, ou cinq, ou ne retenira que de bonnes intentions. Et cela fonctionnera probablement. Les quatre documents que j’ai utilisés sont maintenant sur GitHub. Pas comme un dogme, ni comme un modèle. Plutôt comme des Artefacts archéologiques. "Voici ce qu’une personne a fait une fois, une certaine semaine de 2025." Regarde-les si tu veux, inspire-toi, confonds-toi. Puis ignores-les totalement et crée le tien. Ce ne sont pas des instructions—ce ne sont que des preuves que quelque chose a fonctionné une fois, pour quelqu'un. Évaluation Par des Professionnels de l’Industrie Les experts de l’industrie reconnaissent que nous sommes dans une ère de transformation radicale. L'approche du développement en IA est novatrice et disruptrice. Les traditions et les meilleures pratiques du passé semblent s'effacer devant la nécessité d’explorer de nouvelles méthodes, parfois chaotiques, souvent expérimentales. Cette dynamique est à la fois effrayante et passionnante. Pour les développeurs, la possibilité de faire avancer leurs projets à une vitesse sans précédent offre d'énormes opportunités, mais la constante innovation rend la maîtrise totale impossible à atteindre. Profil de l’Entreprise L’entreprise derrière Protocollie n’est pas une startup conventionnelle. Conçue autour de la collaboration humain-IA, elle explore de nouvelles frontières en matière de développement rapide de logiciels. Son succès initial souligne l'importance d'être flexible et adaptable, d’accepter l'imperfection et de profiter de l'incertitude pour innover constantement. Protocollie n’est pas qu'un produit, c’est également une démonstration vivante des capacités de l'IA dans le développement logiciel, invitant les autres à expérimenter et à pusher les limites.