Introduction
L'IA générative est, par nature, aléatoire.
Notre métier consiste à concevoir et maintenir des systèmes fonctionnels et sécurisés, répondant à des règles métiers précises pour des utilisateurs réels.
Ces deux mondes ne sont pas aussi compatibles que l'on souhaite nous le faire croire. Si le récit actuel est séduisant, un peu de recul permet de constater que 99% de ce narratif repose sur des projets de type "greenfield" (un projet tout neuf). Le pourcentage restant, les projets "brownfield" (un projet legacy), sont peu, voire pas du tout, abordés.
Pourtant, ces projets existent. À notre niveau, nous devons pouvoir garantir que si deux demandes identiques sont formulées (ne serait-ce que sur deux projets distincts), le résultat sera le même. C'est un impératif de gestion d'entreprise et de ressources vis-à-vis d'un donneur d'ordre, qu'il soit interne ou externe.
Le but de cet article est donc de présenter quel cheminement de pensée différent nous pourrions adopter pour tenir la promesse "gain de temps + fiabilité", tout en exploitant le potentiel de l'IA générative.
Qu'est-ce que l'industrialisation ?
Dans nos métiers, industrialiser consiste à définir une stratégie permettant d'automatiser, de sécuriser et de standardiser les tâches récurrentes. L'industrialisation apporte le déterminisme.
L’industrialisation est indissociable de l’automatisation : elle apporte la mise à l’échelle, la fiabilité et la réduction des coûts, avec pour objectif ultime d'améliorer la qualité globale.
Prenons l'exemple d'un linter (un outil permettant de corriger automatiquement des problèmes de syntaxe ou de style). Si un dev lance cet outil sur son propre ordinateur à chaque fois pour vérifier ses erreurs, nous sommes dans l'automatisation d'un processus : la qualité. Le problème est que cette démarche reste limitée à un individu, qui pourrait d'ailleurs en modifier les règles de manière isolée.
L'industrialisation, en revanche, consiste à intégrer ce même outil dans une CI/CD, rendant ainsi l'opération systématique au travers d'un processus standardisé. Toute l'équipe est alors soumise aux mêmes règles, au même outil et au même flux de travail. C’est là que réside la véritable industrialisation.
Le problème de l'IA générative
Dans le cas de l'IA générative, nous avons beau utiliser le même outil (Claude Code, par exemple), le même modèle et le même prompt, rien ne nous garantit le résultat.
Il est inutile de faire semblant : par conception, on ne peut pas anticiper ce qui sortira du LLM avant d'avoir exécuté la requête au moins une fois. Une fois la première requête passée, on peut certes contraindre le modèle à utiliser un cache pour obtenir une sortie identique, mais il reste impossible de garantir a priori la réponse au prompt : "Bonjour, réponds-moi 'bonjour'".
La réponse pourrait être un simple "Bonjour", tout comme elle pourrait être "D'accord, bonjour !" ou "Entendu, je vous réponds bonjour".
Le résultat n'est donc pas prédictible, nous devons composer avec cet état de fait. La question cruciale devient alors : comment procéder, alors que mon métier, lui, n'est pas aléatoire ?
Notre cas d'étude : Créer et maintenir son propre serveur de recettes Symfony
Cet article fait suite à un retour d’expérience personnel : ma redécouverte de l’écosystème PHP et plus particulièrement de Symfony, après presque huit mois d’absence.
Si vous avez un peu de bouteille sur Symfony 2, vous avez connu l’époque où toutes les agences web et les sociétés gérant de nombreux projets en parallèle tentaient de réinventer leur propre version du framework via des distributions et/ou des bundles pré-configurés. Tout le monde avait sa solution "maison", et tout le monde a fini par comprendre qu'il était en train de bâtir des usines à problèmes. Ce fut pourtant un passage nécessaire qui a permis, par la suite, de rationaliser et d’améliorer le framework.
Pour l’anecdote : si vous voulez identifier les rescapés de cette époque, dites simplement PrependExtensionInterface trois fois à voix haute dans un meetup.
L’histoire progresse et l’équipe Symfony a alors une idée de génie. Dans l’écosystème PHP, nous n’avons, pour faire simple, qu’un seul gestionnaire de paquets : Composer. Celui-ci possède des plugins. Et si un plugin permettait d’associer la version d’une dépendance à des recettes d’installation pré-configurées ?
C’est ainsi qu’est né Flex. Après plusieurs itérations, le plugin a évolué pour être aujourd'hui totalement intégré à l’écosystème. Deux éléments nous intéressent particulièrement dans Flex :
- À l'installation : Pour une dépendance fraîchement installée, des fichiers (le plus souvent de configuration, mais pas seulement) sont automatiquement ajoutés au projet. Comme ces fichiers sont créés et validés via un système de Pull Requests, ils sont maintenus dans le temps et considérés comme fiables par la communauté.
- À la mise à jour : Pour une dépendance mise à jour, le plugin propose d'actualiser la configuration. Il s'assure de l'absence de conflits via Git et, en cas de problème, n'applique pas la nouvelle version de la recette tout en levant des alertes.
Symfony a donc industrialisé la création et la maintenance des projets pour la totalité de son écosystème : c’est à l’échelle, sécurisé et standardisé.
Pourquoi créer son propre serveur de recettes ?
On ne crée pas un serveur de recettes sans une excellente raison.
On crée un serveur de recettes parce que les critères de qualité d'une entreprise (ou d'un projet) ne coïncident pas nécessairement avec les standards de la communauté. Les motivations peuvent être multiples : une configuration spécifique, des paramètres de sécurité particuliers, une architecture de projet imposée ou encore l'utilisation de bundles développés en interne.
Le plugin Flex étant particulièrement bien conçu, il permet de déclarer son propre serveur de recettes. C’est précisément ce point qui nous amène à la suite de notre réflexion.
Le point de vue C-level
La raison d'être d'un serveur de recettes personnalisé est fondamentalement simple : passer du temps à réinstaller et reconfigurer une application pour s'assurer qu'elle corresponde aux critères techniques de la société n'a aucune valeur ajoutée.
Ne cherchez pas : cela n'a aucune utilité. Personne n'a envie de payer quelqu'un pour effectuer ce genre de tâches répétitives, d'autant plus lorsqu'une entreprise vend des dizaines de projets par an.
C'est même plus critique : confier cette opération à un humain ne garantit absolument pas l'application systématique de toutes les règles fixées. Sans cette automatisation, la cohérence entre les projets disparaît, l'information se perd et passer d'un projet à l'autre, bien qu'ils soient théoriquement "identiques", devient fastidieux. On finit par découvrir des anomalies au fil du temps, etc.
Créer un serveur de recettes, du point de vue d'un C-level, c'est donc s'assurer que la création de projet est industrialisée et conforme aux standards de qualité. Cela permet de franchir un cap dans l'excellence opérationnelle, d'optimiser la gestion des coûts et, par extension, la rentabilité des projets.
Le point de vue dev
Du point de vue du dev, créer un serveur de recettes présente l'avantage d'obliger à prendre de la hauteur sur les outils et les pratiques que l'on utilise au quotidien. Lors des mises à jour, cela force également à se replonger dans la documentation de Symfony ainsi que dans celle des bibliothèques associées, ce qui favorise une montée en compétences continue. À mon sens, c'est un excellent point qui s'inscrit directement dans une logique de "gestion de carrière".
Cela permet aussi de placer sa valeur au bon endroit. Comme nous l'avons souligné dans l'article précédent : il s'agit de "faire mieux" et pas nécessairement "faire plus".
Vous aurez cependant compris que si vous ne mettez plus que dix minutes à amorcer un projet incluant l'intégralité des critères techniques de l'entreprise, vous aurez, par extension, produit davantage. Cela s'appelle un KPI (indicateur clé de performance) et les directions adorent ce genre de métriques pour les primes de fin d'année.
Mon cas personnel
Tout le monde me connaît pour de sombres histoires de DDD, d'architecture hexagonale, de Clean Architecture, d'Action Domain Responder et de tout un tas d'autres joyeusetés. Ma société a même historiquement recruté une personne explicitement pour la réécriture d'un équivalent d'API Platform pour la génération d'interfaces utilisateurs, tout en garantissant la compatibilité avec nos architectures standards et personnalisées. Et cela fonctionne vraiment très bien (et pas uniquement pour l'administration).
Tout cela pour dire que, de mon côté, une recette qui me crée un dossier src/Controller (pour ne citer que cet exemple) avec une configuration YAML classique ne m'intéresse pas. Je n'ai rien contre cette approche, mais ce n'est pas ainsi que je consomme le framework.
Pour information, en août dernier, avant d'aller explorer d'autres langages, je pouvais garantir le bootstrap complet d'un projet Symfony + API Platform + Sylius Stack en 7 minutes, premier déploiement inclus (merci le PaaS), avec pipelines et services tiers configurés grâce à l'utilisation de recipes.
Le problème
Vous l'aurez anticipé : un serveur de recettes, cela se maintient. Il faut suivre l'évolution du framework, surveiller les serveurs officiels, analyser les diffs, et vérifier si nos personnalisations sont toujours valides avec les nouvelles versions.
C'est un travail de veille et de mise à jour constant pour s'assurer que l'automatisation ne devienne pas, avec le temps, un vecteur d'obsolescence.
Passer de 30% de réussite à 100% de fiabilité
Nous sommes en 2026 et nous faisons tout avec l'IA générative. Même des API, parce qu'il est apparemment "plus cool" de concevoir des interfaces avec Claude plutôt que de maîtriser la spécification OpenAPI, celle-là même qui garantit pourtant une génération client/serveur fiable dans 100% des cas (je sens que je m'égare).
Bref, nous voyons apparaître des partisans du « tout IA générative », oubliant que le résultat n'est pas prédictible : « Donnez-moi 1 000 lignes de spécifications, Monseigneur, nous obtiendrons peut-être le résultat attendu. »
Évidemment, cela ne fonctionne pas : avec un taux de réussite de 30% au premier essai [1, 2], on consomme un nombre de tokens incroyable pour un résultat incertain. Et, soyons honnêtes... nous valons mieux que ça.
Mais on fait comment alors ?
À partir du moment où l’on accepte que l’IA générative n’est pas l’outil universel, il faut revenir aux fondamentaux. Nos bases nous enseignent une démarche en trois étapes :
- Identifier un besoin opérationnel : sans besoin réel, pas d’automatisation, et donc pas d’industrialisation.
- Déterminer le périmètre : s'agit-il d'une recette officielle ? D'un simple fichier YAML à transformer en PHP ? De paramètres à injecter ? Est-ce pour un projet unique ou pour une flotte entière ?
- Chercher des solutions techniques.
Mon cas d'usage
Mes contraintes sont spécifiques : je n'applique pas les règles standards du framework, je modifie l'arborescence (directory structure), je transforme le YAML en PHP et j'utilise des bibliothèques non couvertes par les recettes officielles. De plus, je travaille en rolling release : je démarre toujours sur les dernières versions et je ne touche au legacy qu’en cas de faille de sécurité. Je dois donc répéter ces ajustements à chaque nouvelle version.
La stratégie de résolution
Ma première intuition a été de regarder du côté de l'Open Source. Il existe déjà des solutions qui, via une orchestration de bibliothèques et de la CI, convertissent le YAML en PHP. Mais cela ne couvrait pas l'intégralité de mes besoins.
- Pour la création : Le choix est limité. Si une recette officielle existe, elle est récupérée et transformée en PHP. Il ne me reste qu'à la modifier. Fin de l'histoire.
- Pour la mise à jour : C’est là que cela se corse. Il faut récupérer la nouvelle version de la recette, l'ancienne, analyser le delta, déterminer les modifications à reporter et tout vérifier deux fois. C'est un processus épuisant et chronophage.
L'IA comme levier d'automatisation, pas comme moteur
C'est ici que nous allons utiliser notre expertise pour déléguer l'exécution à notre LLM favori, afin de créer un système qui automatisera cette mise à jour. Décomposons :
- J’ai une recette personnalisée.
- Je télécharge la recette officielle la plus proche et je la compare à la mienne : c'est un diff.
- Je récupère la version supérieure officielle et je tente d'y appliquer mes changements : c'est un patch.
Plutôt que de demander à l'IA de "deviner" la mise à jour, on lui demande de générer les scripts. Nous réfléchissons en tant qu'experts ou experte et le LLM exécute l'implémentation.
Des problèmes surgiront forcément. Par exemple, une simple Yoda condition empêchera l'application d'un patch. Un outil déterministe échouera là où une IA "essaierait" de deviner. Et c'est exactement ce que nous voulons : le fail-fast. Si l'entrée est mauvaise, le système s'arrête.
En résumé : nous utilisons l'IA générative pour construire les outils qui nous permettront de nous passer de l'IA générative. Pour une même entrée, nous obtenons désormais la même sortie, ou une erreur explicite.
C’est ainsi que l’on passe de 30% de réussite à 100% de fiabilité.
Ma solution : AWF (AI Workflow Framework)
Ma solution repose sur un workflow AWF, un outil que je développe pour concevoir des flux d'automatisation mêlant outils en ligne de commande (CLI) et agents IA. Parce que j'ai pris le temps de mûrir ma réflexion, j'ai créé au sein d'AWF un skill Claude spécifique : il me permet de générer des workflows (avec un résultat, certes, non déterministe) puis de les valider et de les exécuter via un moteur, lui, 100% déterministe.
L'intégralité du workflow a été conçue par Claude. Ce flux exécute différents scripts chargés de récupérer, comparer et appliquer les changements version par version, tout en gérant les échecs. En cas d'erreur, une journalisation précise et un diff me permettent d'identifier immédiatement le fichier problématique et de trancher pour appliquer manuellement les modifications.
Une gestion d'erreur au service de la fiabilité
Côté gestion d'erreurs, j'interromps systématiquement le traitement d'un paquet si une mise à jour ne peut pas être appliquée. Je suis alors contraint de vérifier, d'arbitrer et de relancer le processus pour valider la nouvelle version. Une fois corrigée, cette version devient la nouvelle référence : elle a été améliorée et les versions futures ne devraient donc plus présenter le même problème.
Je repasse ensuite dans une phase de vérification de ces mises à jour (lecture de la documentation, revue de code, etc.). L'outil ne m'exempte pas de mon devoir de revue. Cependant, durant cette phase, je peux à nouveau solliciter un agent IA : grâce aux diffs déjà générés, il m'aide à gagner un temps précieux sur la compréhension et la résolution des points de friction.
Conclusion
J'obtiens ainsi un système prédictible à 100%. L'IA n'est que l'un des outils qui m'a permis de bâtir le logiciel capable de maintenir mes recettes. Ce n'est pas l'IA qui maintient mes recettes, c'est l'outil qui a été créé.
C'est une nuance subtile, mais absolument fondamentale pour l'avenir de nos métiers.
Le cas universel de l'API
Le sujet des serveurs de recettes est spécifique aux développeurs Symfony. Pour parler au plus grand nombre, reprenons l’exemple de la création d’API et de leurs clients.
Souvenez-vous d'un principe déjà établi en 2024 : concevoir et mettre à disposition une API qui ne suivait pas la spécification OpenAPI dans du web était, globalement, une mauvaise idée.
Pourquoi ? Parce qu'OpenAPI est un standard. À ce titre, il peut être lu, compris et documenté par une multitude d'outils qui s'appuient sur cette structure pour faciliter l'intégration par des tiers. Un schéma OpenAPI est facilement lisible et modifiable via des interfaces (UI/UX) très performantes. La seule raison valable de ne pas utiliser OpenAPI est d’avoir un besoin qui sort strictement du cadre REST. Et encore : en lisant la documentation, on se rend vite compte que l'on peut traiter des cas « non-REST » très efficacement avec ce standard.
Dans l’écosystème PHP, nous avons d'un côté API Platform, qui génère un schéma OpenAPI nativement, et de l'autre des bibliothèques comme Jane, qui permettent de générer un client complet à partir de ce schéma. Des générateurs équivalents existent dans presque tous les langages, tant pour la partie client que pour la partie serveur.
Cette génération, dès lors que le schéma est conforme à la spécification, fonctionnera dans 100% des cas.
C'est pourquoi, même en 2026 et malgré l'avènement de l'IA générative, il reste une erreur stratégique de produire une API sans respecter la spécification OpenAPI.
En conclusion
Le message que je souhaite vous transmettre est celui de l'importance de la réflexion. À l'heure où tout le bruit ambiant nous incite à ne plus nous poser de questions et à déléguer aveuglément à un LLM, n'oublions pas nos acquis : il est crucial de savoir où et quand utiliser l'IA générative.
Écrire ces scripts seul m'aurait pris un temps fou. Il aurait fallu monter en compétence, éplucher chaque documentation, etc. J'aurais certes acquis une expérience incroyable en Bash, mais une expérience qui, globalement, n'a aucune valeur concrète sur le marché du travail actuel. Cela pourrait relever du hobby, mais personnellement, mes loisirs penchent plutôt vers la guitare et la lecture.
L'IA générative a une valeur immense mais, pour ce besoin précis, je n'appellerais pas un LLM pour transformer directement de la configuration YAML en PHP. Je ne vais pas consommer des tokens et perdre mon temps en croisant les doigts pour un taux de réussite de 30%.
À la place, j’appellerai mon serveur de recettes de manière industrialisée et déterministe. Si j'ai commis une erreur dans une recette, je pourrai la modifier manuellement ou avec l'aide de l'IA, mais j'aurai optimisé ma chaîne de production dans un seul but : faire mieux, plus simple, plus rapide et plus pérenne qu'à la main.
C'est ainsi que je place ma valeur sur des sujets plus essentiels. Cela ne fait pas de moi un "demi-dev" : cela me permet simplement de gagner du temps pour résoudre d'autres problèmes complexes, tout en continuant à monter en compétence.
En résumé : utilisez la règle des « 5 pourquoi » ou toute autre méthode de réflexion, mais surtout, n'abandonnez jamais vos capacités techniques et intellectuelles.
Prochaines étapes
À titre personnel, mes prochaines étapes d'industrialisation pour ces recettes sont claires :
- Publier AWF pour l'intégrer plus facilement dans des pipelines.
- Déclencher des mises à jour automatiques pour générer des Pull Requests.
- Affiner les processus pour aider l'IA à assister les revues de code.
Cela viendra quand cela viendra, mais cela viendra. Et j'aurai alors une industrialisation complète pour cette partie de mon quotidien.