Comment intégrer l'IA sans sacrifier la qualité

Il y a trois mois, une communauté d’écriture que j’affectionnais particulièrement annonçait sa fermeture. J’avais trois mois pour recréer un endroit permettant aux bientôt anciennes Plumes d’atterrir. Trois mois pour recoder un site qui avait évolué pendant dix huit ans. Sur mon temps libre. Dans un langage (PHP) que je n’avais pas touché depuis 2010 (ne jugez pas, s’il vous plaît !). Dans un framework (Laravel) que je n’avais jamais installé sur ma machine.

Trois mois, et 50 000 lignes de code plus tard, nous nous sommes installés dans notre nouveau chez nous (https://jd-esperluettes.fr). Nous n’avons pas atteint la parité de fonctionnalités, parce que nous en avons priorisé d’autres qui nous paraissaient plus importantes. Et ce n’est que le début, car avec une découpe en 21 modules, et plus de 1600 tests d’intégration, la vélocité est stable !

Les IAs agentiques accélèrent sensiblement le processus de production. Et nous offrent une plus grande versatilité.

Quand le langage n’est plus qu’un détail d’implémentation

Je vais vous faire une confidence : je n’aime pas écrire du PHP. Attention, loin de moi l’idée de médire du langage qui propulse la moitié du Web. Les dernières versions ont grandement amélioré la robustesse du langage. Mais tant qu’il faudra écrire “$maVariable->” pour accéder à un champ, tant que j’aurais l’impression de devoir être un contortioniste pour appeler une méthode, je n’aimerai pas l’écrire.

Alors pourquoi diable choisir PHP, et le framework Laravel que je n’avais jamais utilisé, alors que j’avais une deadline aussi serrée ? Est-ce que c’était encore un défi débile de développeur à l’ego surdimensionné ?

Bon. OK. Peut-être. Mais j’aime à penser que ma décision était plus rationnelle que ça. Plusieurs éléments pointaient vers Laravel.

D’abord, une décision économique. Le site est gratuit. L’association est naissante. Il me fallait un hébergement peu cher, idéalement le serveur mutualisé sur lequel traînent tous mes développements pour en arriver à l’impressionante facture de 0€. Ce qDall-Eui me laissait globalement 4 langages disponibles : JS/TS, PHP, Python, Ruby

Mon expertise, c’est le Typescript. J’aurais dû pencher pour mon habituelle stack NestJs / Angular. J’ai plein de modules réutilisables d’autres projets. J’ai une solide maîtrise de Typescript, que j’affectionne particulièrement. Les monorepos avec NX n’ont (presque) aucun secret pour moi.

Mais quelque chose clochait fonctionnellement : le but de l’outil, c’était de proposer une plateforme qui permette aux auteurices de publier et de commenter leurs textes. Principalement du contenu statique donc. Le SEO, la vitesse d’exécution étaient importants. Je n’avais pas le temps de faire un front et un back séparé. Je n’attendais pas des gros niveaux d’interactivité : une SPA ne me servait à rien. Si si, promis, on l’a un peu oublié, mais on peut écrire des sites sans React / Angular / Vue / …

Je n’aime pas PHP, mais je me tiens informé de l’évolution des frameworks majeurs. Tout me criait Laravel, quand bien même mon ego me disait “allez, un petit peu d’Angular, version 20, ça va être cool”. J’ai quand même demandé à Claude, en essayant d’être le plus neutre possible, sans lui cacher que PHP, ce n’était ni ma stack, ni ma tasse de thé. Claude était sûr de son coup : Laravel + Blade (je ne connaissais pas Blade, tiens…), Alpine.Js pour l’interactivité (kézako ?), Tailwind pour le style (après tout le temps que j’ai passé à apprendre CSS ?).

Je n’aime pas PHP, mais c’était le choix le plus logique. Et je connaissais quelqu’un avec qui j’allais passer plusieurs heures par jour, qui se moquait du langage. Brice. Brice, c’est le nom que j’ai donné à mon IA agentique. Pourquoi ? Parce que j’utilise Windsurf, et que… bref, vous aurez sûrement la réf.

Alors j’ai lancé le projet en PHP / Laravel. Trois mois plus tard, aucun regret. Je kiffe la DX (sauf quand il faut écrire “$var->”…). Et les features s’enchaînent.

Un détail, parce que plus haut…

Ok, j’ai laissé à Windsurf la responsabilité d’écrire en PHP, au moins le temps de me souvenir comment le langage fonctionnait. Par contre, je n’allais pas jeter quinze ans d’expérience par la fenêtre. Il y a une chose que je n’allais certainement pas abandonner : l’architecture. J’ai donc immédiatement :

• Établi une stratégie de test qui me permette de remanier l’app au besoin
• Commencé une découpe modulaire qui me permette de garder le contrôle

Car je n’avais pas pour objectif de juste copier le site existant. Je savais que plus j’allais implémenter de choses, plus mes Admines et ma communauté allaient avoir d’idées d’amélioration.

Alors on a posé les bases. J’ai opté pour des tests d’intégration, pour pouvoir refondre l’application à l’envie, car je savais que j’allais faire des erreurs. J’ai fait une première découpe basée Domaines. J’ai exposé des APIs aux autres modules pour qu’ils puissent se servir. J’ai mis une Architecture Event Driven en place pour les communications inter-modules non directes, ou à contre courant.

Et tout du long, j’ai appris aux côtés de Brice. J’ai découvert les Observers Laravel, et j’ai failli hurler sur Brice que ce genre d’effet de bord était ni fait ni à faire, avant de me raviser.

Alors oui, Laravel est un framework MVC. Pour un fan d’architecture hexagonale, de DTOs, de DAOs, me faire injecter le modèle directement dans le contrôleur, ça m’a fait tout drôle. Il m’a fallu un moment pour réaliser que je luttais contre le framework, que je pouvais me permettre d’avoir une architecture moins forte à l’intérieur de mes modules, que cela me permettait d’exploiter au maximum la puissance du framework. Et j’avais les tests, qui couvraient de l’extérieur, donc je n’avais rien à craindre ! Si demain, j’ai besoin de passer un module en hexagonal, on le fera.

Des fois, Brice créait les fichiers au mauvais endroit. Souvent, il mettait les requêtes Eloquent directement dans le Contrôlleur. Mais j’étais en contrôle. En trois mois (250 heures de code probablement), j’ai produit 50 000 lignes de code. C’était inimaginable avant l’arrivée de l’IA. Est-ce que mon code est parfait ? Probablement pas. Mais j’ai un indicateur qui ne trompe pas. Mes 15 bêta testeurs n’ont trouvé qu’un bug logique sur toute la période de bêta-test. Le reste, c’était du cosmétique. On a ouvert le 3 novembre. J’avais posé ma journée, au cas où. J’ai passé la première journée à implémenter pleins de petites améliorations qu’on n’avait pas eu le temps de finaliser. Pas de bug. Sous contrôle. C’est tout ce que je demandais.

Et la tendance continue, car un mois plus tard, j’avais pas loin de 75 000 lignes de code. Les fonctionnalités continuent de sortir en fonction de mon temps libre. Parfois, j’ai besoin de refacto, comme dans tout projet. Mais tant que je suis capable de pointer du doigt les fichiers à modifier à Brice, et de réfléchir aux modifications qu’il devrait faire, je me sens en contrôle, et c’est tout ce qui m’importe.

Je ne suis pas un ingénieur 10x

L’IA ne m’a pas donné des super-pouvoirs. Mais à l’heure où l’IA peut vous écrire des lignes de code plus vite que vous avez le temps de les lire, j’ai pu constater que mon rôle n’avait pas changé. Avant l’arrivée de Brice, mon attention était déjà focalisée sur l’architecture, particulièrement sur la testabilité et la modularité. Avant, je me concentrai déjà sur l’oeuvre cible. La différence, c’est que maintenant, je peux le faire sur plus de langages, plus de frameworks, parce que je peux apprendre ces éléments au fil de l’eau, sans devoir me former pendant des semaines. Car les grands principes théoriques de l’informatique fonctionnent en Java comme en Ruby, avec des subtiles nuances qu’il m’incombe de prendre en compte.