Il existe aujourd’hui plusieurs manières de développer avec l’IA, et elles ne se valent pas. À un bout, le vibe coding, où le prompt tient lieu de source de vérité. À l’autre, des méthodes plus robustes, qui ne sortent pas de nulle part : elles reprennent ce qui se fait déjà dans le cycle de vie logiciel, le SDLC, en l’augmentant à l’IA. Toutes reposent sur un même principe, le spec-driven development, où c’est la spécification, et non le prompt, qui fait référence.

Le SDLC est un domaine très large et je n’en reprends qu’une partie. Mais les principes que j’en tire s’appliquent au développement de n’importe quel module, qu’il s’agisse d’une orchestration d’agents LLM, d’un modèle de machine learning ou d’autre chose. Voici les étapes que je suis.

Cadrer et spécifier : le quoi et le pourquoi

Tout commence par un document qui répond à deux questions seulement : ce qu’on construit, et pourquoi on le construit. C’est le rôle d’un PRD, dans lequel je pose les exigences fonctionnelles et non fonctionnelles.

Une fois ce cadre en place, je le précise dans un document plus détaillé, typiquement un spec.md. Il reste au même niveau : il dit ce que le système doit faire, jamais comment il va le faire. Cette séparation n’est pas une formalité. Mélanger les deux revient à figer des choix techniques avant d’avoir fini de comprendre le besoin, et c’est précisément là que les projets partent de travers.

Planifier : le comment

Ce n’est qu’ensuite, une fois que j’ai tout le quoi, que je passe au comment, dans un plan.md.

C’est la phase la plus cruciale du processus, parce qu’elle est la seule qui demande de prendre du recul sur l’ensemble du système. C’est là qu’on arbitre les choix d’infrastructure et de stack, qu’on challenge ce que propose l’IA, et qu’on s’assure que le projet est réalisable techniquement. Autrement dit, c’est là que les compétences de conception système sont le plus sollicitées, et c’est ce qui fait de cette phase le vrai point de contrôle du développement assisté par IA.

Je brainstorme avec l’IA à ce moment-là, et c’est utile. Mais le plan qui en sort est le produit d’arbitrages, pas d’une acceptation.

Découper en tranches verticales

Le plan une fois écrit, il reste à le transformer en tâches vérifiables. C’est là qu’intervient le choix de découpage qui compte le plus.

Je ne procède pas par couche, en développant d’abord la base de données, puis le back-end, puis le front-end. Je découpe en tranches verticales, qui traversent toutes les couches à la fois. L’intérêt est direct : une tranche produit un comportement observable de bout en bout, donc quelque chose qui se vérifie et qui reste lisible pour un humain. Une couche isolée, elle, ne prouve rien tant que les autres n’existent pas.

Exécuter, une tâche à la fois

Chaque tâche part ensuite en exécution séparément, confiée à un agent qui ne traite qu’elle. C’est bien meilleur que de tout demander d’un coup, et la raison tient moins à la méthode qu’à l’outil : le contexte est déterminant.

Une IA ne doit pas être débordée par un contexte trop grand, car à partir d’un certain volume, celui-ci devient contre-productif. La séparation des tâches répond donc à deux exigences en même temps, la vérifiabilité du résultat et les limites réelles du modèle.

Valider, avant et après

La validation encadre l’exécution des deux côtés.

En amont, avant de lancer une tâche, je m’assure que l’agent dispose de tout ce dont il a besoin pour l’implémenter. En aval, une fois l’implémentation faite, je vérifie le code. Cette vérification est d’autant plus abordable que chaque tâche poursuit un seul objectif et qu’elle est découpée assez finement pour qu’une relecture courte suffise : c’est le découpage qui rend la relecture possible, pas l’inverse.

C’est ensuite à moi de fusionner le travail et de suivre l’avancement de chaque tâche, en fonction des dépendances et de la difficulté. L’agent exécute ; le séquencement, lui, ne se délègue pas.