IA et développement : les outils qui changent vraiment mon quotidien

Introduction : la promesse et la réalité

Depuis l’explosion des LLMs grand public fin 2022, les développeurs vivent sous un déluge de promesses : l’IA va coder à votre place, les développeurs juniors vont disparaître, les seniors seront 10x plus productifs. Un an et demi plus tard, la réalité est plus nuancée — et plus intéressante.

J’ai intégré progressivement plusieurs outils IA dans mon workflow de développeur freelance PHP/Symfony. Voici un retour honnête sur ce qui a changé concrètement, ce qui déçoit encore, et comment j’organise aujourd’hui mon travail avec ces outils.

Les outils testés

Claude (Anthropic)

Mon outil principal pour les questions de fond, la revue de code, la rédaction de documentation et les problèmes d’architecture. Claude excelle dans les raisonnements longs et structurés. Sa capacité à maintenir un contexte cohérent sur une longue conversation en fait un excellent partenaire pour explorer des sujets complexes.

GitHub Copilot

Intégré directement dans VS Code et PhpStorm, Copilot complète le code en temps réel. C’est l’outil le plus transparent à l’usage : on ne change pas son workflow, on accepte ou refuse les suggestions. Il est particulièrement efficace sur le code répétitif et les patterns bien établis.

Cursor

Un éditeur de code construit autour des LLMs. La fonctionnalité la plus utile : le mode “Composer” qui peut modifier plusieurs fichiers simultanément selon une instruction en langage naturel. Utile pour les refactorisations transversales.

ChatGPT (OpenAI)

Moins utilisé au quotidien depuis que j’ai adopté Claude, mais encore utile pour des recherches rapides, des explications de concepts ou des comparaisons de solutions.

Ce qui fonctionne vraiment

Génération de boilerplate

C’est sans doute le gain le plus immédiat et le plus mesurable. Générer une entité Doctrine avec ses getters/setters, un FormType Symfony, une migration de base de données, une classe de test unitaire vide — toutes ces tâches répétitives qui ne demandent pas de réflexion mais consomment du temps.

Avant : 15-20 minutes pour scaffolder une feature CRUD complète. Avec l’IA : 3-5 minutes de vérification et d’ajustements.

Écriture des tests

Donner une classe à Claude avec l’instruction “génère les tests unitaires PHPUnit pour cette classe” produit en général une base de tests correcte et complète. Je vérifie, j’ajuste les cas limites, mais la structure est là. La productivité sur la couverture de tests a augmenté significativement.

Documentation et commentaires

Documenter une API, écrire les docblocks PHPDoc, générer un README — des tâches que je remettais souvent au lendemain. L’IA les rend presque instantanées.

Revue de code et détection d’anomalies

Coller un bloc de code dans Claude avec “qu’est-ce qui pourrait poser problème ici ?” révèle souvent des bugs subtils ou des problèmes de sécurité que je n’avais pas vus. C’est devenu une étape systématique avant de pousser du code.

Ce qui déçoit (encore)

L’architecture complexe et le contexte métier

Demander à une IA de concevoir l’architecture d’une application métier complexe donne des résultats génériques. Elle ne connaît pas les contraintes spécifiques du client, les décisions de conception prises il y a six mois, les raisons pour lesquelles on a choisi tel pattern plutôt qu’un autre.

L’IA est bonne pour implémenter une solution bien définie. Elle est mauvaise pour définir quelle solution implémenter.

Le code legacy et les contextes implicites

Sur un projet existant avec ses propres conventions, ses hacks historiques et ses dépendances spécifiques, l’IA génère souvent du code qui ne s’intègre pas bien. Elle travaille dans le vide sans la connaissance du contexte global.

La confiance aveugle dans les suggestions

C’est le risque principal : accepter les suggestions sans les comprendre. J’ai vu des développeurs moins expérimentés intégrer du code généré par IA qu’ils ne comprenaient pas, créant des bugs difficiles à déboguer et des problèmes de sécurité. L’IA amplifie les compétences existantes ; elle ne les remplace pas.

Mon workflow actuel

1. Conception et architecture : seul, sur papier ou avec un collègue. L’IA n’intervient pas ici.
2. Scaffolding et boilerplate : Copilot en temps réel, Claude pour les structures plus complexes.
3. Implémentation : Copilot pour les suggestions en contexte, Claude pour débloquer les problèmes.
4. Tests : Claude génère la base, je complète les cas limites.
5. Revue avant commit : Claude pour une dernière passe sur la sécurité et la qualité.
6. Documentation : Claude pour la rédaction, je relis et j’ajuste le ton.

Risques à prendre au sérieux

Dépendance et atrophie des compétences : à force de faire générer le code, certains développeurs perdent de la fluidité sur les tâches de base. Je m’impose régulièrement des sessions sans assistance IA pour maintenir mes compétences.

Propriété intellectuelle : le statut du code généré par IA reste juridiquement flou selon les pays. Pour les clients avec des exigences strictes de propriété, c’est un point à clarifier contractuellement.

Qualité et hallucinations : l’IA peut générer du code qui semble correct mais qui est subtilement faux, ou citer des APIs inexistantes. La revue humaine reste indispensable.

Confidentialité : les prompts envoyés aux services cloud contiennent parfois du code métier sensible. J’utilise les modes entreprise quand ils sont disponibles, et je reste vigilant sur ce que je partage.

Conclusion : outil, pas remplaçant

Un an après avoir intégré sérieusement ces outils, le bilan est positif sur la productivité — avec des nuances importantes. L’IA m’a rendu plus efficace sur les tâches répétitives et m’a libéré du temps pour les problèmes qui demandent vraiment de la réflexion.

Mais elle n’a pas changé ce qui fait la valeur d’un développeur expérimenté : comprendre le métier du client, prendre des décisions d’architecture durables, identifier les vrais problèmes derrière les symptômes. Pour ça, il faut encore des humains.