AI SDLC : un recueil de bonnes pratiques pour développer avec l'IA

Il y a beaucoup de hype autour du développement assisté par l’IA. Claude, Copilot, Cursor… la liste s’allonge chaque semaine. Et oui, ces outils sont puissants. L’IA est excellente pour un PoC, mais passer en production, c’est une autre histoire.

Qu’est-ce que l’AI SDLC ?

L’AI SDLC, c’est l’intégration d’outils et de systèmes d’IA dans chaque phase du cycle de développement logiciel traditionnel — planning, analysis, design, coding, testing, deployment et maintenance — pour renforcer le développeur humain et améliorer la vitesse, la qualité et la prise de décision. Comme le résume IBM dans cet article, l’idée n’est pas de remplacer le dev, mais d’ajouter une couche intelligente tout au long du processus. Et ils mettent en garde contre un point clé : le code généré par l’IA « may look correct, but can contain subtle problems » — il peut sembler correct tout en cachant des problèmes subtils. C’est pourquoi l’approche human-in-the-loop est presque obligatoire sur tout projet sérieux.

Cet article ne cherche pas à couvrir les sept phases. C’est un recueil de bonnes pratiques pendant l’AI SDLC, centré sur la partie où le dev est le plus dans la boucle : conception, construction et revue. Ce n’est pas la vérité absolue ; vous trouverez bien d’autres pratiques et standards en creusant. C’est ce qui fonctionne pour moi.

L’IA est géniale pour un PoC — mais un PoC n’est pas prêt pour la prod

Les AI dev tools sont fantastiques pour partir de zéro et avoir rapidement quelque chose qui fonctionne. Vous lui dites ce que vous voulez, vous la laissez tourner, et en quelques minutes vous avez un PoC. Le problème, c’est que ce code ne suit pas forcément les bonnes pratiques de conception, d’architecture ou de coding. Dans la plupart des cas, ce qui en sort n’est pas un produit prêt pour la production.

Et voici la partie inconfortable : vous devez comprendre le code. Le vibe coding convient pour une maquette, pas pour quelque chose de prod-grade. Et c’est toujours vrai, même avec le dernier modèle et les meilleurs outils.

Les scénarios : là où l’IA brille et là où ça se complique

Créer un PoC entièrement fonctionnel à partir de zéro — très bien. C’est là qu’elle brille le plus.
Ajouter des features simples à un codebase — bien. En général, pas besoin de beaucoup plus d’aide.
Ajouter des features complexes à un codebase complexe — moyen. Là, il faut déjà nettement plus de guidance de la part du dev.
Modifier des features existantes dans un codebase simple — bien. En général, moins de guidance.
Modifier une feature existante dans un gros codebase — bien. Toujours sans trop de guidance.
Implémenter une feature complexe dans un gros codebase — c’est là que ça devient difficile. Peu importe le contexte, les skills ou les hooks dont vous disposez, ni la qualité de votre prompt : il vous faut un bon plan. Il est très facile pour l’agent de générer du code loin d’être idéal — probablement du code qui fonctionne, mais peu scalable, sujet aux erreurs, peu lisible, etc.
Les gros codebases en général, et les migrations de code — les choses deviennent vraiment délicates.

Conclusion : plus le codebase est gros et complexe, et plus la feature est complexe, plus l’utilité de l’IA livrée à elle-même baisse — et plus l’importance du dev dans la boucle augmente.

Quand vous passez en prod : mon workflow d’AI SDLC

Quand vous voulez mettre quelque chose en production, le vibe coding n’est pas la réponse — du moins pas si vous comptez sur l’agent pour tout faire. Voici les bonnes pratiques que j’applique, issues de mon expérience personnelle :

1. Concevez avant de prompter

Avant d’écrire le moindre prompt, c’est vous qui décidez de l’architecture, de la conception et du langage. Vous pouvez faire du brainstorming avec l’IA, mais vous devriez avoir conçu à l’avance chaque aspect de l’application et de l’infra.

2. Demandez-lui un plan détaillé

Utilisez cette conception et demandez à l’IA de générer un plan détaillé, avec vos instructions et vos décisions déjà prises en entrée.

3. Relisez le plan !

Attentivement. Demandez toutes les modifications nécessaires. Je lui demande généralement de créer un fichier .md que l’IA et moi pouvons modifier et relire — je ne le laisse pas seulement dans le prompt.

4. Découpez et avancez

Une fois le plan validé, découpez les grosses tâches en petites tâches et lancez-vous.

5. Ne la laissez jamais tout faire sans demander

Relisez chaque changement. Finalisez un commit. À ce stade, j’aime relire encore une fois les changements du commit. Le code généré par l’IA a l’air bon, et il est facile de laisser passer des problèmes en une seule lecture. Quand vous êtes satisfait de ce commit, passez à l’étape suivante.

6. Revue finale, en trois exemplaires

Quand tout est prêt, demandez à l’IA de relire une dernière fois pour trouver d’éventuels problèmes. Et faites vous-même une inspection manuelle rapide de votre nouveau code. C’est la troisième revue.

D’autres pratiques à garder en tête

Les tests comme garde-fou

Demandez à l’IA d’écrire des tests, mais avec un œil critique. Elle génère parfois des tests qui passent trivialement, ou qui testent l’implémentation au lieu du comportement réel. Les tests sont votre filet de sécurité quand vous laissez l’agent modifier le code, mais il faut les relire avec la même méfiance que le reste. Un test qui n’échoue jamais ne vous protège de rien.

Sécurité : ne faites jamais confiance aveuglément

L’IA glisse facilement des secrets en dur, des dépendances non sûres, des validations manquantes ou des vulnérabilités d’injection. Ça fonctionne, mais ça laisse la porte ouverte. Relisez toujours le code généré sous l’angle de la sécurité : quelles données il manipule, ce qu’il valide, ce qu’il expose.

Des outils déterministes dans la boucle

Tout n’a pas à passer par votre jugement ou par celui du modèle. Linters, type checkers, formatters et CI détectent automatiquement une foule de choses que ni vous ni l’agent ne devriez vérifier à la main. Laissez les outils déterministes faire leur travail et gardez votre attention pour ce qui demande vraiment du discernement.

Attention au scope creep

L’agent a tendance à « améliorer » des choses que vous n’avez pas demandées, ou à toucher des fichiers hors du périmètre de la tâche. Soudain, un simple changement arrive avec trois refactors surprise. Gardez-le concentré sur ce que vous avez demandé ; les changements hors périmètre sont l’un des moyens les plus faciles d’introduire des bugs que personne n’attendait.

Sachez quand l’écrire vous-même

Parfois, expliquer à l’IA comment faire quelque chose coûte plus cher que de le faire à la main. Reconnaître ce moment est une compétence en soi. L’IA est un outil, pas une obligation : si vous allez plus vite en écrivant le code vous-même, écrivez-le.

Choisissez le bon modèle et le bon effort pour chaque tâche

Tout ne mérite pas le modèle le plus puissant à l’effort maximal. Pour les tâches simples — renommer, refactors mécaniques, boilerplate — un modèle plus léger suffit largement. Gardez les gros modèles et le reasoning élevé pour ce qui en a vraiment besoin : architecture, features complexes, débogage difficile. Économiser des coûts et des tokens n’est pas qu’une question d’argent : adapter le modèle et l’effort à la complexité réelle de la tâche donne de meilleurs résultats et moins de bruit.

Quelques règles importantes

Assurez-vous que vos skills, hooks, commands, rules et le code styling sont configurés dans le contexte de l’agent et prêts avant de commencer.
Profitez des rules pour fixer les comportements non négociables de l’agent : « ne suppose jamais rien », « vérifie ou demande toujours si quelque chose n’est pas parfaitement clair », « ne touche pas aux fichiers hors du périmètre de la tâche », « n’invente ni API ni bibliothèques ». Une bonne rule vous évite de répéter la même chose dans chaque prompt.
Faites des adversarial reviews de votre projet.
En général, les solutions simples sont les meilleures. Méfiez-vous des solutions complexes générées par l’IA — il existe souvent un chemin plus direct que le modèle n’a pas choisi.
Si vous n’êtes pas sûr de la meilleure façon d’implémenter quelque chose, revenez à la source : documentation officielle, specs, code d’origine. Ne vous contentez pas de la première réponse de l’agent.
Ne mettez en prod rien que vous ne comprenez pas.