La question « l’IA peut-elle écrire du code prêt pour la production » est mal posée, mais c’est celle que les directions continuent de formuler. L’IA écrit déjà du code dans votre base Laravel, car vos développeurs l’utilisent ; interdire son usage revient simplement à ce que cela se fasse sans discipline de relecture.
La question utile est plus précise : quelles erreurs commet-elle sur ce framework en particulier, et que doit donc vérifier un relecteur ? Laravel est un bon cas d’étude : ses conventions sont fortes, sa documentation excellente, et il est très représenté dans les données d’entraînement — ce qui produit un style confiant, idiomatique, parfois risqué.
Contexte à la rédaction : Laravel 13 (mars 2026) propose un SDK IA stable et des outils officiels pour le développement assisté par agent, et l’équipe du framework travaille publiquement sur la question de la conformité des agents au style Laravel. Le sujet évolue vite ; la politique de relecture ci-dessous vise à rester pertinente au-delà des outils.
Là où l’IA apporte une aide fiable
La précision est essentielle, car une politique générale dans un sens ou l’autre est inadaptée.
- Génération de code standardisé — contrôleurs de ressources, formulaires de requête, factories, seeders, ressources API. Les conventions Laravel sont si bien représentées que le code généré ici est généralement correct et cohérent.
- Génération de squelettes de tests. Générer les cas que vous auriez écrits, mais que vous auriez pu négliger, notamment sur les cas limites de validation.
- Refactorisations mécaniques sur de nombreux fichiers — renommage, extraction, mise à jour d’un appel obsolète. Fastidieux, peu de jugement, facile à vérifier.
- Explication de code inconnu. Réellement utile sur une base héritée, sans risque pour la mise en production.
- Migrations et définitions de schéma à partir d’un modèle décrit — vérifiables à la lecture, et les erreurs sont évidentes.
Où cela échoue, de façon prévisible
Ce sont les cas que nous observons régulièrement, et c’est sur eux qu’une politique de relecture doit porter.
1. Requêtes efficaces mais non évolutives
Les requêtes N+1 sont l’erreur typique. Un code généré qui boucle sur une collection et accède à une relation dans la boucle est correct, lisible, passe ses tests sur un jeu de dix enregistrements, et s’effondre sur des données réelles. Le modèle ne sait pas que votre table orders contient neuf millions de lignes.
2. Autorisation supposée plutôt qu'appliquée
Les contrôleurs générés omettent souvent la vérification de la politique d’accès, ou la placent à un endroit facile à contourner. C’est le risque le plus élevé : le code fonctionne parfaitement pour le développeur qui teste en tant qu’administrateur.
3. Vieilles pratiques issues de données d'entraînement obsolètes
Les données d’entraînement privilégient ce qui a été le plus écrit, ce qui n’est pas nécessairement à jour. Sur un framework avec dix ans d’articles, cela signifie du code généré selon des conventions de versions anciennes : helpers obsolètes, validation dépassée, schémas remplacés par des fonctionnalités natives. Cela paraît plausible parce que cela l’a été.
4. Affectation massive et confiance excessive dans les entrées
Le code généré transmet trop souvent les entrées de la requête directement à la création du modèle. La protection de Laravel limite les dégâts, mais seulement si le modèle est bien configuré, ce qui n’est pas toujours le cas pour du code généré.
5. Contextes multi-locataires et portées
Si votre application isole les données par locataire, organisation ou marque, le code généré l’ignore, sauf si l’architecture rend l’oubli impossible. C’est un argument fort pour imposer le scope au niveau de la base de données ou du modèle de base, plutôt que par convention — point détaillé dans architecture multi-tenant Laravel.
6. Invention trop assurée
Noms de méthodes inexistants sur vos classes, API de packages jamais publiées, clés de configuration plausibles. Faciles à détecter — cela échoue immédiatement — mais cela gaspille du temps de relecture et détourne l’attention des erreurs plus subtiles.
La politique de revue
Assez courte pour être suivie.
- L’auteur indique l’origine du code. Une pull request précise si le code est en grande partie généré par IA. Non pour pointer du doigt, mais pour guider la relecture.
- L’auteur a lu chaque ligne. Toute la politique tient en une phrase. Soumettre du code non relu est la vraie faute ; l’outil de génération n’est qu’un détail.
- Quatre vérifications obligatoires sur le code généré : comportement des requêtes sur des données volumineuses, autorisation, validation et mass-assignment, et contexte de scope ou de locataire.
- L’analyse statique est obligatoire. PHPStan ou Psalm au niveau réellement tenu par votre code, en CI, bloquant. Le code généré mérite des standards imposés par la machine.
- Les tests doivent être écrits ou vérifiés par un humain. Un agent qui écrit à la fois le code et le test peut produire un couple cohérent entre eux, mais non conforme au besoin.
- Aucun code généré ne doit toucher à la frontière de sécurité sans relecture par une seconde personne. Authentification, autorisation, paiement, toute manipulation de données personnelles.
- Migrations et opérations destructives exigent un auteur humain. Une migration générée qui supprime une colonne est aussi crédible qu’une qui en ajoute une.
La politique inefficace : l’interdiction. Les équipes utilisent ces outils de toute façon, et l’interdiction transforme un problème de relecture en problème de transparence, ce qui est pire.
Faciliter la conformité du code
L’action la plus efficace n’est pas de relire plus. C’est de rendre l’erreur difficile à écrire, ce qui aide aussi les contributeurs humains.
- Imposez l’autorisation structurellement, pour qu’une action de contrôleur sans vérification de politique échoue au lieu de passer silencieusement.
- Imposez le scope locataire dans le modèle de base ou la base de données, pour qu’une requête non scoppée échoue.
- Maintenez des types stricts et un niveau élevé d’analyse statique. Les deux réduisent fortement l’espace du code plausible mais erroné.
- Documentez réellement les conventions dans le dépôt. Les agents lisent le dépôt ; une base qui documente ses propres schémas produit un meilleur code, pour les agents comme pour les nouveaux arrivants.
- Gardez la base de code idiomatique. La cohérence devient une propriété lisible par la machine autant que par l’humain — un schéma inhabituel produit un résultat inhabituel.
Ce dernier point est la vraie nouveauté. Un code conventionnel et une bonne documentation étaient auparavant un confort justifié par la rapidité d’intégration. Ils sont désormais un facteur direct de la qualité d’une part significative du code produit : c’est un argument économique, non plus stylistique.
Mesurer l'impact réel
Les éditeurs vendent un gain de productivité. Mesurez le vôtre, car la réalité varie fortement selon la tâche.
- Temps de cycle du premier commit à la fusion, pas le nombre de lignes produites. Ici, le volume est un anti-indicateur.
- Charge de relecture — temps passé à relire, et nombre d’itérations avant validation. Si le temps de relecture augmente plus que celui d’écriture ne baisse, vous avez déplacé le coût, pas réduit.
- Taux de défauts par modification fusionnée, suivi séparément pour le code assisté par IA et celui écrit manuellement.
- Taux de réécriture — fréquence à laquelle un code fusionné est réécrit de façon significative dans le mois.
- Où se concentrent les gains. Notre expérience : ils sont réels et importants sur le code standardisé et les tests, faibles sur la logique métier, parfois négatifs sur ce qui exige une connaissance de votre système.
Observez-le pendant un trimestre avant de l'intégrer à votre planification de capacité. Une équipe qui part d'une hypothèse de productivité et dimensionne ses effectifs en conséquence fait un pari coûteux sur un chiffre que personne n'a mesuré.
C'est le travail de gouvernance que notre équipe Laravel applique sur les bases de code client, en parallèle de la question plus large de la place réelle de l’IA dans la livraison — sujet de notre pratique d’intégration IA et de notre équipe d’ingénierie IA. Le même schéma d’échec apparaît plus nettement sur du code ancien : voir pourquoi les agents de codage IA maîtrisent les usages PHP 7.
Questions fréquentes
Faut-il autoriser les développeurs à utiliser des outils d’aide à la programmation par IA ?
Ils les utilisent déjà ; interdire leur usage transforme une pratique contrôlable en pratique cachée. La bonne approche consiste à imposer une politique de revue courte et ciblée sur les erreurs typiques de ces outils, et à structurer le code pour rendre difficile l’introduction d’erreurs.
Quelles sont les erreurs les plus fréquentes du code Laravel généré par IA ?
Des requêtes N+1 qui passent les tests sur de petits jeux de données, des contrôles d’autorisation absents ou mal placés, des idiomes de versions anciennes du framework surreprésentés dans les données d’entraînement, des affectations massives non protégées, et tout ce qui relève du contexte spécifique à votre application, comme la gestion des tenants.
Le code généré par IA présente-t-il un risque de sécurité ?
Le risque se concentre sur des points prévisibles : autorisation, gestion des entrées et tout ce qui touche aux données personnelles. Traitez ces zones comme nécessitant systématiquement une seconde relecture humaine, quel que soit l’auteur, et imposez autant que possible des contrôles structurels plutôt que de compter sur la vigilance en revue.
L’assistance par IA accélère-t-elle réellement les équipes ?
De façon mesurable sur le code standardisé, la génération de squelettes et les refontes mécaniques. Beaucoup moins sur la logique métier, et parfois négativement si le travail dépend de la connaissance de votre système. Mesurez le temps de cycle, la charge de revue et le taux de reprise sur un trimestre avant d’ajuster la capacité sur la base d’un gain supposé.
Comment la revue de code doit-elle évoluer avec l’IA ?
Indiquez l’auteur pour orienter la revue, exigez que l’auteur ait lu chaque ligne, et ajoutez quatre contrôles obligatoires : comportement des requêtes en production, autorisation, validation des entrées et affectation massive, ainsi que le contexte tenant ou scope. Appuyez-vous sur une analyse statique bloquante.
Adopter la politique, puis mesurer
Nous vous aidons à définir la politique de revue et les garde-fous structurels, puis à mettre en place la mesure qui vous indiquera si cela porte ses fruits. Contactez notre équipe ; nous répondons sous un jour ouvré.