IA et développement web : un changement de paradigme

Vingt ans de développement web nous ont appris à nous méfier des outils qui devaient tout changer. Beaucoup ont fini oubliés dans un coin de GitHub. L'IA générative aurait pu rejoindre cette liste. Mais depuis six mois, quelque chose a basculé dans notre façon de travailler sur un projet Laravel. Ce n'est pas Claude Code tout seul. C'est la combinaison Claude Code + Laravel + Laravel Boost, et elle reconfigure la phase de développement au point que nous ne faisons plus tout à fait le même métier.

Notre thèse se résume en une phrase. L'IA n'invente rien, elle adapte des solutions rodées. Plus notre projet ressemble à des patterns établis, plus elle est utile. Le cadre fait l'IA, bien plus que l'inverse. Et paradoxalement, l'expertise humaine devient plus décisive qu'avant, pas moins.

Trois vagues d'outils en quatre ans

Pour comprendre ce qui se joue aujourd'hui, il faut regarder les trois vagues d'outils IA qui ont transformé le développement depuis 2021. Chacune a apporté un saut qualitatif, et c'est la combinaison des trois qui donne la situation actuelle.

La première vague, c'est GitHub Copilot. Preview technique ouverte le 29 juin 2021, disponibilité générale comme produit payant le 21 juin 2022. Copilot a introduit l'autocomplétion contextuelle dans Visual Studio Code. L'outil lit le code autour du curseur et propose les lignes suivantes, inspirées de milliards d'autres projets qu'il a vus passer. Chez Microsoft, Satya Nadella a annoncé en juillet 2025 avoir dépassé les 20 millions d'utilisateurs cumulés. Les chiffres de janvier 2026 parlent d'environ 4,7 millions d'abonnés payants et de 90 % du Fortune 100 équipé. Copilot, à lui seul, a habitué une génération entière de développeurs à coder avec un copilote dans l'éditeur.

La deuxième vague, c'est Cursor, lancé en 2023 par la startup Anysphere. Plutôt que d'ajouter de l'IA à un éditeur existant, Cursor est un fork de VS Code pensé dès le départ pour l'IA. L'outil voit tout le projet, pas seulement le fichier ouvert. Il édite plusieurs fichiers à la fois, propose des refactorings à l'échelle du dossier, comprend la structure d'un codebase complet. L'adoption a été rapide. En juin 2025, Anysphere lève 900 millions de dollars en série C à une valorisation de 9,9 milliards. En novembre 2025, série D de 2,3 milliards, valorisation 29,3 milliards, plus d'un million d'utilisateurs actifs quotidiens. Ce n'est plus une curiosité, c'est devenu un outil standard dans une part significative de l'industrie.

La troisième vague, c'est Claude Code, sorti en preview par Anthropic en février 2025, disponible en version stable en mai 2025 avec la famille de modèles Claude 4. Le changement de nature est là. Claude Code n'est plus un autocomplète ni un éditeur augmenté. C'est un agent qui tourne dans un terminal, qui lit un dépôt, édite des fichiers, lance des tests, relit les sorties et corrige. Anthropic a communiqué en décembre 2025 sur une croissance d'utilisateurs de plus de 300 % depuis l'introduction des modèles Claude 4, avec un revenu multiplié par 5,5. La version web est sortie le 20 octobre 2025.

Un chiffre de contexte pour situer le mouvement d'ensemble. Le Stack Overflow Developer Survey 2025, publié fin décembre sur la base de près de 50 000 répondants dans 177 pays, rapporte que 84 % des développeurs utilisent ou prévoient d'utiliser l'IA dans leur travail, contre 76 % l'année précédente. Ce n'est plus un signal faible, c'est le nouveau normal.

Ces trois vagues partagent un point commun qu'on ne voit pas de l'extérieur. Aucune n'écrit du code original. Elles réassemblent des patterns qui existent déjà sur GitHub, Stack Overflow, dans les documentations officielles et les forums techniques. Cette observation, qui pourrait sembler décevante, est en réalité la clé de compréhension de ce qui rend l'IA efficace ou inefficace sur un projet donné.

L'IA n'invente rien et c'est une bonne nouvelle !

Une IA générative ne crée pas de patterns nouveaux. Elle reconnaît des patterns qu'elle a vus pendant son entraînement, les adapte au contexte spécifique d'un projet, les recombine pour répondre à la demande. Ce constat technique a une conséquence très concrète pour quiconque commande un site web. Plus le projet s'appuie sur des patterns établis et documentés, plus l'IA est précise. À l'inverse, un projet sans conventions claires, où chaque fichier a sa propre façon de faire, produit une IA qui dérive rapidement.

C'est pour cette raison qu'un framework opinionated comme Laravel est un terrain particulièrement favorable. Laravel impose des conventions fortes depuis quinze ans. Les modèles Eloquent se nomment au singulier, les tables au pluriel. Les contrôleurs RESTful suivent une structure précise. Les validations passent par des Form Requests. Les tests s'écrivent en PHPUnit ou Pest. Ces conventions, documentées et répétées dans des milliers de projets open source, sont exactement ce que l'IA sait reproduire avec le plus de précision.

WordPress suit la même logique. Les hooks, les filters, les types de contenu personnalisés, la structure d'un thème ou d'une extension, tout cela est normé depuis plus de vingt ans. Un développeur WordPress chevronné reconnaît au premier coup d'œil un code qui respecte les standards de celui qui les ignore. L'IA applique le même jugement, à la différence qu'elle le fait automatiquement quand elle écrit.

Cette lecture rejoint ce que nous avons décrit dans notre article sur l'open source et la colonne vertébrale du web. Les frameworks libres et les standards ouverts ont construit, au fil des années, des patterns partagés que des milliers de développeurs ont testés, documentés, corrigés. Ces patterns collectifs sont aujourd'hui le carburant de l'IA. Elle n'est efficace que parce qu'une quantité massive de code de qualité est disponible publiquement pour entraîner les modèles.

La conclusion pratique est simple. La vraie question n'est pas "est-ce que l'IA va coder à notre place". C'est "est-ce que notre projet offre à l'IA un cadre qui lui permet d'être bonne". La réponse se trouve dans le choix de la stack technique, dans la rigueur des conventions, dans la qualité de la documentation interne. Des choix qui étaient déjà importants avant l'IA, mais qui deviennent déterminants avec elle.

Laravel Boost ou quand le framework parle à l'IA

Le premier outil qui nous a vraiment convaincus que l'IA avait changé de nature, c'est Laravel Boost. Sorti le 13 août 2025 par Ashley Hindle, annoncé à la conférence Laracon US quelques semaines plus tôt, Boost est un package officiel Laravel qui résout un problème précis. Avant Boost, quand nous demandions à Claude Code d'écrire du code Laravel, il produisait du code Laravel générique. Il connaissait Laravel dans l'absolu, mais pas la version installée dans notre projet. Il ne connaissait pas l'état réel de la base de données, les routes définies, les erreurs récentes, les packages réellement chargés.

Boost repose sur trois briques qui corrigent tout cela. La première est un serveur MCP spécifique à Laravel, qui expose neuf outils que l'agent peut appeler pendant qu'il travaille. La deuxième est une base de documentation vectorisée et versionnée, avec plus de 17 000 entrées, qui permet à l'IA de chercher de la doc spécifique aux versions exactes installées dans le projet. La troisième est un ensemble de guidelines composables, maintenues par les core team Laravel, qui cadrent la manière dont l'IA doit écrire du code pour ce projet.

Ce qu'installe la commande boost:install

Concrètement, nous lançons une commande dans le terminal du projet, php artisan boost:install. Boost détecte les agents IA présents sur la machine et dans le projet, puis propose d'installer les guidelines, les skills Laravel et la configuration du serveur MCP. Pour Claude Code, il génère un fichier CLAUDE.md à la racine du projet et un fichier .mcp.json qui connecte l'agent au serveur MCP de Boost.

Le CLAUDE.md généré n'est pas un fichier statique livré tel quel. Il est composé à l'installation à partir de templates, en fonction des packages réellement détectés dans le projet par un outil interne appelé Roster. Si le projet utilise Livewire 3, les règles Livewire 3 sont incluses. S'il utilise Inertia 3, les règles Inertia 3 le sont. S'il est sur Laravel 12 et PHP 8.3, les règles sont scopées à ces versions. Ce détail change tout par rapport à un CLAUDE.md écrit à la main, qui devient rapidement obsolète ou incohérent avec la vraie stack.

Extraits du CLAUDE.md par défaut

Quelques exemples de ce que Laravel Boost demande à l'IA, traduits du fichier officiel. La première règle, qui sert de fondation à tout le reste, est la suivante : "Tu dois suivre toutes les conventions de code existantes de l'application. Quand tu crées ou modifies un fichier, regarde les fichiers voisins pour la structure correcte, l'approche et le nommage." Cette consigne, en apparence banale, est ce qui empêche l'IA de mélanger trois styles différents dans le même projet.

Deuxième règle, spécifique à Boost : "Laravel Boost est un serveur MCP avec des outils conçus pour cette application. Préfère les outils Boost aux alternatives manuelles comme les commandes shell ou la lecture de fichiers." Concrètement, quand l'IA veut connaître la version de Laravel installée, elle appelle l'outil application-info plutôt que d'ouvrir composer.json. Plus fiable, plus rapide, moins sujet aux erreurs.

Troisième règle, celle qui a le plus d'impact sur la qualité des suggestions : "Utilise toujours search-docs avant de faire des modifications de code. Ne saute pas cette étape. Cet outil retourne de la documentation spécifique aux versions des packages installés dans ce projet." Avant Boost, une IA pouvait proposer du code qui marchait en Laravel 10 mais plus en Laravel 12 parce qu'une méthode avait changé. Avec search-docs, elle consulte la doc de la version exacte et évite ces écarts.

Autres règles utiles, qu'on retrouve dans le fichier généré : "Utilise les commandes Artisan make: pour créer de nouveaux fichiers comme les migrations, les contrôleurs et les modèles", "Ne crée pas de scripts de vérification ou n'utilise pas Tinker quand des tests couvrent déjà la fonctionnalité. Les tests unitaires et de feature sont plus importants", "Déclare systématiquement declare(strict_types=1) en haut de chaque fichier PHP", "Utilise la promotion de propriétés par constructeur de PHP 8".

Les neuf outils MCP exposés par Boost

Le serveur MCP de Boost met à disposition de l'agent neuf outils qu'il peut appeler pendant qu'il travaille. application-info donne les versions PHP et Laravel, le moteur de base de données, les packages installés, les modèles Eloquent détectés. browser-logs lit les logs du navigateur pour déboguer un problème front. database-connections liste les connexions configurées. database-query exécute des requêtes en lecture seule sur la base de développement. database-schema retourne le schéma d'une table. get-absolute-url résout une URL de route. last-error récupère la dernière erreur remontée. read-log-entries lit les logs applicatifs récents. search-docs fait la recherche sémantique dans la documentation versionnée des 17 000 entrées.

L'enjeu dépasse la liste des fonctionnalités. Avant Boost, l'IA savait Laravel de manière générique et datée. Son corpus d'entraînement avait vu du Laravel 8, 9, 10 en vrac. Quand nous lui demandions une requête Eloquent, elle piochait au petit bonheur. Avec Boost, elle connaît la version exacte installée, l'état réel de la base, les erreurs actuelles, les routes définies. Elle devient contextuelle. C'est une différence de nature, pas de degré.

Le TDD retrouve son sens

Le développement piloté par les tests, le TDD, a été formulé par Kent Beck il y a plus de vingt ans. L'idée est connue. On écrit le test avant le code. Le test décrit le comportement attendu. On écrit ensuite juste assez de code pour que le test passe. On refactorise. On recommence. Dans la pratique, beaucoup d'équipes ont abandonné ou dilué cette discipline parce qu'elle demande du temps que les plannings ne prévoyaient pas.

Avec un agent IA, l'équation change. Le test bien écrit devient le cahier des charges exécutable. Nous écrivons le test. L'agent implémente. Il lance les tests. Si le test échoue, il ajuste. Il continue jusqu'à ce que le test passe. La discipline qui paraissait chronophage devient économique, parce que la partie coûteuse, l'écriture du code d'implémentation, est portée par l'agent.

Kent Beck lui-même, qui code depuis cinquante-deux ans, a décrit cette évolution dans une interview donnée à la newsletter The Pragmatic Engineer en juin 2025. Il parle d'une pratique ré-énergisée, d'un TDD devenu "superpouvoir" avec les agents IA. Pour quelqu'un qui a vu passer des dizaines de modes, la formule a du poids.

Cette nouvelle mécanique n'est pas sans piège, et Beck le signale honnêtement. Un agent IA, confronté à un test qu'il n'arrive pas à faire passer, peut être tenté de modifier ou de supprimer le test plutôt que de corriger le code. Le contrôle humain reste nécessaire. Nous relisons systématiquement les tests que l'agent écrit ou modifie, et nous vérifions que les tests qui passent testent bien ce que nous voulions tester.

La valeur d'un bon test n'a pas changé. Il documente l'intention, il protège des régressions, il oblige à formaliser ce qu'on veut avant de coder. Ce qui change, c'est que la discipline devient accessible à des équipes qui ne pouvaient pas se la permettre avant. Un test bien écrit au début d'une fonctionnalité économise des heures de débogage plus tard, et il permet à l'agent de s'auto-corriger au lieu de produire du code plausible mais faux.

Le développeur expérimenté devient chef d'orchestre

Un projet web classique comporte quatre phases. Cahier des charges, développement, tests, mise en ligne. Historiquement, le centre de gravité était dans le développement. Un développeur senior passait l'essentiel de son temps à écrire du code, à déboguer, à refactoriser. Avec l'arrivée des agents IA dans le workflow, ce centre de gravité se déplace. Le développement brut devient plus rapide. Le cadrage, la spécification et la vérification deviennent plus longs et plus importants.

Concrètement, sur les projets Laravel récents que nous avons livrés, nous n'écrivons plus la grande majorité du code à la main. Nous cadrons en amont. Nous définissons l'architecture, les conventions, les contraintes de sécurité. Nous rédigeons les specs des fonctionnalités avec assez de précision pour qu'un agent IA puisse les implémenter. Nous déléguons l'écriture du code. Nous relisons systématiquement ce qui est produit. Nous arbitrons techniquement quand deux approches sont possibles.

Ce que nous vérifions à chaque fois n'a pas changé. Cohérence avec l'architecture existante. Sécurité, en particulier sur la validation des entrées, les autorisations, les accès en base. Gestion des cas limites et des erreurs. Conformité stricte aux spécifications fonctionnelles. Pertinence et couverture des tests. Ce sont les points sur lesquels une IA peut produire du code qui tourne sans pour autant être correct, et c'est là que l'œil humain reste déterminant.

Ce que l'IA fait très bien aujourd'hui, sans supervision minutieuse, couvre une part importante du quotidien. Le boilerplate Laravel. Les migrations. Les Form Requests. Les requêtes Eloquent standard. Les tests Pest ou PHPUnit de base. Les refactorings mécaniques. L'adaptation d'une fonctionnalité d'un contexte à un autre. Tout ce qui relève de patterns reconnus et bien documentés est exécuté avec une précision qui dépasse, dans beaucoup de cas, ce qu'un développeur humain produirait à la main en dix fois plus de temps.

Ce qu'elle fait moins bien sans supervision se situe ailleurs. Les choix d'architecture, quand plusieurs patterns sont envisageables et que le bon choix dépend de critères externes au code. La gestion d'état complexe, où les interactions entre composants créent des subtilités qu'un LLM a du mal à tenir en tête. Les optimisations fines, qui demandent de comprendre le comportement réel du système à l'échelle. La logique métier spécifique, quand elle n'est pas documentée et que l'IA n'a aucun moyen de la deviner.

La conséquence opérationnelle pour une agence comme la nôtre est nette. Un développeur senior expérimenté peut aujourd'hui encadrer plus de projets en parallèle sans perte de qualité, à condition que le cadre de chaque projet tienne. Les conventions doivent être claires. Les specs doivent être précises. La supervision doit être systématique sur les zones sensibles. Si une de ces conditions manque, la productivité apparente se paie en dette technique à moyen terme.

Pour le client qui nous confie un projet, ce déplacement est invisible dans le quotidien mais il change les termes du contrat. Le devis sur la phase de développement pur est souvent plus court qu'il y a deux ans. La phase de spécification et de validation est souvent plus longue, et c'est là que nous investissons le temps libéré. La qualité finale au moment de la mise en ligne est au moins équivalente, souvent supérieure, parce que la couverture de tests est beaucoup plus systématique qu'avant.

Pour un développeur junior, le changement est un défi. L'IA écrit aujourd'hui le code qu'un junior aurait écrit pour apprendre. Si le junior délègue simplement, il ne comprend pas ce qu'il livre. Il doit compenser en passant beaucoup de temps à lire et à comprendre ce que l'IA produit, pas à déléguer aveuglément. Nous reviendrons sur ce point plus bas.

Ce que l'IA ne remplace pas (et ne remplacera pas de sitôt)

Cette description pourrait donner l'impression que l'IA résout à peu près tout. Ce n'est évidemment pas le cas, et plusieurs zones de fragilité doivent être nommées clairement, sous peine de vendre du miracle à nos clients et de livrer des projets qui ne tiennent pas.

Sans cadre, rien ne fonctionne. Si le cahier des charges est flou, l'IA produit du code cohérent avec sa propre interprétation du besoin, pas avec ce que le client voulait vraiment. La phase de spécification devient plus importante qu'avant, pas moins. C'est un constat contre-intuitif pour les clients qui s'attendent à ce que l'IA fasse tomber les contraintes de spec. En pratique, l'inverse se produit. Une spec floue donne un projet flou, avec juste plus de vitesse pour s'égarer.

La revue de code humaine reste indispensable sur les zones sensibles. Paiement, authentification, gestion de données personnelles, accès à des API externes, traitement de fichiers uploadés. L'IA produit du code plausible. Plausible n'est pas correct. Un code qui gère un flux de paiement peut passer tous les tests automatisés et laisser une faille critique si le développeur qui l'a supervisé n'a pas pensé à un cas particulier. Ces zones demandent toujours un regard d'expert, avec la responsabilité qui va avec.

L'arbitrage technique reste un acte humain. Choisir entre deux architectures quand les deux sont valides, dire non à une demande qui va casser l'existant, négocier un compromis entre performance et simplicité, ces décisions engagent le projet dans la durée. Une IA peut proposer les options. Elle ne porte pas la responsabilité du choix. Sur un projet client, quelqu'un doit porter cette responsabilité, et ce quelqu'un reste humain.

Un chiffre d'honnêteté intellectuelle mérite d'être cité. En juillet 2025, l'organisation METR a publié une étude contrôlée et randomisée sur seize développeurs expérimentés travaillant sur des projets open source qu'ils connaissaient bien en moyenne depuis cinq ans. Deux cent quarante-six tâches ont été réalisées, la moitié avec accès aux outils IA (Cursor Pro, Claude 3.5 et 3.7 Sonnet), l'autre moitié sans. Les développeurs pensaient, avant l'étude, que l'IA les accélérerait de 20 %. Ils pensaient, après l'étude mais avant d'avoir vu les résultats, qu'elle les avait accélérés de 20 % également. En réalité, sur ces tâches précises, l'IA les a ralentis de 19 %. Une réplication publiée en février 2026 a confirmé le ralentissement, autour de 18 %, avec un intervalle de confiance large. L'IA n'est pas un accélérateur automatique. Elle est un outil, et comme tout outil, elle demande à être utilisée avec discernement sur les tâches où elle excelle vraiment. Sur un projet Laravel bien cadré, l'expérience est très différente de celle d'un développeur open source plongé dans un codebase de quinze ans qu'il connaît par cœur.

Enfin, et c'est peut-être le point le plus durable, l'utilisateur final d'un site web reste un humain. Les parcours d'achat, les hésitations devant un bouton, les micro-signaux de confiance, le ton d'un texte, les détails qui rassurent ou qui font partir. Ce que l'IA comprend d'un humain qui clique reste beaucoup plus pauvre que ce qu'un œil humain voit en dix secondes sur une maquette ou une vidéo de test utilisateur. L'UX reste primordiale, et elle n'est pas près d'être automatisée de bout en bout. Les agents IA qui se multiplient dans le paysage, et les protocoles comme le MCP qui leur permettent d'interagir avec des systèmes tiers, peuvent faire évoluer ce constat pour certains cas d'usage. Des IA qui achètent un billet d'avion ou réservent un restaurant à la place de l'utilisateur, ça existe déjà. Mais tant que le client final d'un site e-commerce est un être humain sur son canapé avec son téléphone, l'ergonomie, le ton et la confiance restent un travail d'humain pour humain.

Apprendre sans IA, la compétence qui reste

Un paradoxe mérite d'être souligné en conclusion de ce panorama. Plus l'IA est bonne, plus les compétences qui permettent de juger ce qu'elle produit deviennent rares et précieuses. Savoir lire une documentation officielle de bout en bout. Comprendre comment un navigateur parle à un serveur, comment une requête HTTP est construite, comment une base de données indexe les enregistrements, comment un framework MVC route les appels. Visualiser les interconnexions entre une migration, un modèle, un contrôleur, une vue, un test.

Nous avons tous appris à coder avant l'IA. À chercher dans les manuels, à décortiquer des exemples, à réparer du code qui ne marchait pas en comprenant pourquoi il ne marchait pas. Ces compétences ne sont pas un réflexe nostalgique. Elles sont la base qui nous permet aujourd'hui de relire ce qu'un agent produit, de détecter quand il se trompe, d'arbitrer entre deux solutions qu'il propose, de refuser une suggestion qui irait casser l'architecture existante.

Pour un développeur junior qui commence aujourd'hui, le piège serait de court-circuiter cet apprentissage. L'IA peut livrer du code fonctionnel sans qu'on ait compris ce qu'elle fait. Six mois plus tard, quand ce code doit être maintenu ou étendu, le junior qui a délégué sans comprendre se retrouve face à du code qu'il n'a jamais vraiment possédé. Face à un bug subtil, il ne sait pas par où commencer.

Ce n'est pas un conseil moral, c'est une observation technique. Les développeurs qui tirent le meilleur de Claude Code aujourd'hui sont ceux qui savaient déjà coder sans. Ils ont le cadre mental pour évaluer les suggestions, pour demander la bonne chose, pour reconnaître quand l'agent se perd. Un junior qui veut suivre cette trajectoire doit continuer à faire l'effort d'apprendre les fondamentaux, documentation par documentation, même quand une IA pourrait lui donner la réponse plus vite. L'IA amplifie ce qui est déjà là. Si la compréhension technique n'est pas là, elle ne sera pas amplifiée.

Surfer la vague, pas s'y noyer

Ce qui change dans notre métier avec l'IA générative est concret, mesurable, et probablement durable. La phase de développement brut devient plus rapide. L'allocation du temps d'un senior se déplace vers le cadrage et la vérification. Certaines tâches répétitives disparaissent ou deviennent triviales. Les conventions, les frameworks opinionated et la documentation versionnée prennent une valeur qu'ils n'avaient pas il y a cinq ans.

Ce qui ne change pas mérite d'être rappelé avec autant de netteté. Un client qui nous commande un site web n'achète pas "moins de code humain". Il achète un projet livré dans les délais, testé, sécurisé, maintenable dans la durée. L'UX reste humaine. Les choix d'architecture restent des décisions qui engagent. La responsabilité technique reste entière. Et l'accompagnement, la pédagogie, la confiance qui se construit sur un projet restent des dimensions humaines.

Les terrains où l'IA donne aujourd'hui le meilleur ne sont pas un hasard. Laravel, WordPress, les frameworks open source aux conventions établies, les standards ouverts comme le Model Context Protocol qui dépasse les 97 millions de téléchargements SDK mensuels en mars 2026 et compte plus de 10 000 serveurs actifs, donné à l'Agentic AI Foundation sous l'égide de la Linux Foundation en décembre 2025. Ce sont des écosystèmes collectifs, construits par des milliers de contributeurs, documentés et testés à grande échelle. L'IA excelle là où l'intelligence collective a préparé le terrain.

La vague est là, elle ne repartira pas. La question à se poser n'est plus "faut-il l'utiliser", mais "avec quel cadre". Chez MtoM Création, c'est la question que nous posons au début de chaque projet, parce que la réponse détermine la qualité de ce que nous livrerons et la pérennité de ce que nos clients mettront en ligne.