J'ai décidé de coucher par écrit mon avis sur l'IA (ou plus précisément, l'utilisation de LLMs) après plus d'un an d'utilisation. Bien sûr c'est un avis personnel et votre expérience peut être différente, mais ce sont les leçons que j'ai apprise suite à cette expérience.

Mon expérience avec les LLMs

Déjà commençons par parler de mon expérience avec les LLMs histoire de savoir d'où je parle. Comme indiqué précédemment, j'ai plus d'un an d'expérience dans leur utilisation. La liste des différents LLMs que j'ai utilisé est assez longue :

Anthropic Sonnet 3 / 3.5 / 3.7 / 4 / 4.5
Anthropic Haiku 4.5
OpenAI GPT 3.5 / 4 / 4o / o1-preview / o1-mini / 01 / 03-mini / OSS-120B
Google Gemini 2.0 Flash / 2.0 Pro / 2.5 Flash / 2.5 Pro
DeepSeek R1
MoonshotAI Kimi K2
z.AI GLM-4.6

J'ai également utilisé un certain panel d'outils, tout d'abord au niveau des IDE/éditeur de code :

Jetbrains PHPStorm/Goland (avec Github Copilot, (feu) Supermaven, Jetbrains AI Assistant ou Jetbrains Junie en fonction des périodes et des besoins)
VSCode avec Github Copilot/Chat ou Cline
Cursor
Trae
Neovim avec le plugin copilot
Zed avec Github Copilot ou Supermaven ou Zed AI

Pour le reste des outils :

L'API d'Antropic pour utiliser leur différents LLMs
L'API d'OpenAI pour la même chose
OpenRouter pour factoriser les deux et avoir accès à bien plus de LLMs (comme Gemini Flash, Kimi-K2 par exemple)
Un tout petit peu d'utilisation de serveurs MCP (en particulier Context7)

L'utilisation des LLMs s'est fait quasi-exclusivement dans le cadre de mon activité, celui d'être un développeur (backend spécialisé dans le PHP) et j'ai aujourd'hui quatre ans d'expérience en tant que professionnel au niveau PHP, et 6 à 7 ans en tant que développeur de manière globale.

Pour l'utilisation elle-même, c'est essentiellement dans le cadre du développement, c'est à dire générer du code, faire du debug, poser des questions, etc... Je ne l'utilise pas pour auto-review des pull request, ou encore compléter des tickets ou auto-corriger du code. Et cette utilisation a eu lieu à la fois en milieu professionnel (en accord avec les responsables, parfois poussé par eux-même), mais également sur des projets personnels.

Ce n'est pas la révolution attendue

Tout d'abord je souhaite préciser qu'il y a un potentiel biais étant donné que je fais essentiellement dans le backend, avec du PHP habituellement et que les modèles sont potentiellement plus efficaces pour du JavaScript et du Python, mais personnellement je trouve que la génération de code PHP n'est pas vraiment au point.

En fait ce n'est pas tout à fait exact, c'est relativement fonctionnel dans le cadre de la suggestion monoligne ou de quelques lignes (via Github Copilot ou Supermaven via la touche TAB). Là où les choses se corsent, c'est lorsqu'on demande de générer des fonctions, des classes ou encore des fonctionnalités entières.

Et là directement, quelque soit la génération de LLM (Sonnet 3.7, Sonnet 4, Sonnet 4.5, GPT 01-mini, Gemini Flash 2.0 Pro ou 2.5 Pro), le résultat était quelques fois bons (mais très rarement en one-shot), souvent moyens, parfois très mauvais pour les raisons que je vais énoncer par la suite.

Trop d'hallucinations

C'est l'un des gros problèmes des LLMs, toujours à l'heure actuelle, les modèles ont trop tendance à inventer des méthodes qui n'existent ni dans la codebase, ni dans le langage de programmation ou du framework, ce qui fait que le code généré ne peut pas fonctionner.

Dans certains cas cela va même modifier des méthodes qui sont appelés en y mettant du code non fonctionnel et risquant de casser d'autres parties de l'application. Et ça devient d'autant plus problématique quand ça en profite pour modifier les tests qui sont liés au code modifié, pouvant casser la logique fonctionnelle où le réel cheminement de ce qui doit être testé.

Les limites contextuelles

Autre problème de taille, figurativement et littéralement, sur les tailles de contexte que peuvent gérer les LLM et surtout la manière dont ils naviguent dans ces contextes. Cela m'arrive sans arrêt de voir les LLMs qui génèrent du code qui n'est pas écrit dans le même style que le code existant ou encore utilisant des méthodes dépréciés (par le langage ou le framework) ou n'utilisant pas les dernières fonctionnalités du langage quand le projet explicite la version qu'il utilise (comme dans le composer.json pour PHP).

Actuellement la plupart des LLM ont un contexte d'environ 200 000 tokens (en gros), quelque uns comme Google peut étendre cela à un million de tokens (ou encore la beta de Sonnet 4.5). Le problème est que même si le contexte est étendue, il ne semble pas comprendre correctement la codebase lorsque cette dernière est importante et/ou complexe (c'est à dire avec beaucoup de règles métier et/ou fonctionnelles pas forcément explicites) ou de manière plus problématique à mon sens, qu'il oublie des choses dans le contexte présent si ça "date" un peu (dans le sens ce n'est pas le début de la discussion et ce n'est normalement pas hors contexte).

Ce n'est pas prêt de remplacer un développeur (qui est un minimum compétent)

Au delà des "compétences" techniques des LLM, il y a surtout une chose sur laquelle ils sont mauvais : la compréhension métier et de l'équilibre entre répondre aux besoins métiers, et les contraintes techniques qui y sont liés, et cela pour le moment, les LLM sont mauvais sur ce point.

Et cela vient du fait que le contexte métier, les LLM l'ont rarement et jamais, et ils n'arrivent pas à le déduire à partir du code (parfois ils vont essayer si tout est suffisamment explicite, mais ça corresponds quasi jamais au contexte de l'entreprise), ce qui fait que les solutions proposées ne sont pas adaptées.

Mais tout n'est pas noir

Cependant il est possible de mitiger une partie de leur limite en s'astreignant à plusieurs actions.

Intégrer un `.rules` au sein du projet

C'est un fichier qui permet les différentes règles que doit normalement suivre un LLM. Généralement on y met le rôle que dois prendre le LLM (par exemple : "Considère-toi comme un expert PHP"), éventuellement quelques informations sur le métier de manière générale, puis les spécificités du projet et des règles qu'on veut que ça suive (par exemple : "C'est un projet PHP 8.4 et Symfony 7.3, ça utilise également PestPHP 4 pour les tests. Ça suit la clean architecture", etc...)

Cela permet de cadrer un peu le LLM dans ce qu'il doit générer au lieu de passer la moitié du temps à le corriger parce que ça ne suit pas du tout les conventions du projet.

Après il faut avoir en tête qu'il arrive que le LLM ignore une partie des règles indiquées quand même. À prendre aussi en compte que ce qui est écrit dans le .rules sera décompté du budget du contexte que ça génère un "coût minimum" pour chaque nouveau thread de discussion avec le LLM. Donc plus le .rules est important en taille, plus le prix de base va augmenter (ce qui peut chiffrer vite avec certains modèles).

Plutôt efficace dans un contexte répétitif

Le contexte où je trouve qu'il se débrouille le mieux, c'est l'écriture des tests. Pour cela il faut d'abord avoir écrit à la main un ou des tests (si l'architecture des tests est différent en fonction du contexte de la fonctionnalité, du domaine et/ou du type), puis une fois que cela est fait, pour les prochaines fonctionnalités développées, il suffit de mettre en référence le test en question en lui demandant d'écrire les tests relatifs à la fonctionnalité nouvellement développée.

Dans ce cadre ça permet d'avoir des tests qui sont écrits à 80-90% correctement, tout en ayant généralement ajouté plus de cas d'utilisation que ce qu'on ferait généralement habituellement. Attention parce qu'il faut toujours vérifier la sortie du LLM quand même pour vérifier que les tests qu'il a généré sont pertinents et réellement fonctionnels (et non des faux-positifs).

Se limiter à des contextes restreints

Là encore, il s'agit de limiter le niveau d'information pour éviter que le LLM parte dans tous les sens.

Cela signifie de se limiter à générer une fonction, ou de faire une refacto limitée, au lieu de vouloir développer une fonctionnalité entière, limiter au maximum le nombre de fichiers impliqués (au mieux que ça ne concerne que le fichier en cours et les tests liées).

J'ai observé que plus le contexte est restreint, plus le LLM est efficace.

Changer de modèle en fonction du besoin

Autre chose à considérer pour limiter les coûts, utiliser différents modèles de LLM en fonction de la tâche à effectuer. Pour des tâches relativement simple, il suffit d'utiliser par exemple Kimi-K2 ou encore Haiku 3.5 (voir des modèles moins onéreux comme GPT-OSS ou GLM-4.6).

Pour des tâches plus complexes, c'est à dire relativement longues ou qui doivent mélanger plusieurs concepts comme utiliser une lib en conjonction du framework utilisé en traitant les données d'une manière spécifique, le mieux est d'utiliser Claude Sonnet 4.5 ou GPT-5 par exemple.

Utiliser un MCP pour récupérer de la documentation

Dernière action qui peut être assez utile, c'est d'utiliser un serveur MCP comme Context7 pour que le LLM récupère les documentations de ce que vous indiquez ou de ce qui est utilisé dans les fichiers. Par exemple à la fin de votre prompt, vous pouvez ajouter use context7 mcp après l'avoir configuré dans votre éditeur, pour lui dire de l'utiliser. Ça va l'aider à mieux utiliser les langages ou les différentes librairies afin de moins halluciner sur ce qu'il doit générer.

Bon alors, au final ?

De la hauteur de mon expérience seulement, je suis relativement mitigé. D'un côté c'est loin d'être le remplaçant des développeurs comme on peut le voir/lire dans les media grand public (voir même par les gros fans d'IA sur LinkedIn), mais en l'encadrant très fortement et d'avoir les bons réflexes pour savoir à quel moment et de quelle manière utiliser un LLM, ça permet d'aller plus vite à mon sens.

L'autre cas intéressant, en prenant toutes les précautions indiquées auparavant, c'est pour s'initier à un nouveau langage ou apprendre à implémenter un service (comme Firebase/Supabase, une librairie externe, etc...).

Bref c'est loin d'être capable de développer des applications en vibe coding de manière correcte (et sécurisée) ou même de s'appuyer fortement dessus, mais ça peut être un bon assistant à condition de le traiter comme un développeur très junior qui a beaucoup de connaissances, mais aucune expérience.