Comment nous structurons le développement assisté par IA chez Ambris

mai 26

Depuis quelques mois, l’IA fait partie du quotidien des développeurs.

Chez Ambris, nous l’utilisions déjà régulièrement pour :

générer des fonctions
expliquer du code
produire des tests unitaires
analyser des erreurs

Bref, comme beaucoup d’équipes : un assistant de développement plutôt efficace.

Mais assez vite, une question est apparue.

Et si l’IA pouvait faire plus que générer des snippets ?

Et si elle pouvait participer à tout le cycle de développement d’une fonctionnalité ?

C’est cette question qui nous a amenés à expérimenter une approche qui commence à être théorisée aujourd’hui :

AIDD — AI-Driven Development

L’idée est simple : structurer un workflow où l’IA accompagne toutes les étapes d’une feature, depuis la description initiale jusqu’aux tests.

Le vrai défi : la taille du contexte

Quand on commence à utiliser l’IA sérieusement dans le développement, on se heurte vite à un problème.

Les modèles ont une fenêtre de contexte limitée.

Si on empile tout :

description de la feature
spécification fonctionnelle
spécification technique
plan d’implémentation
plan de tests
code

le modèle finit par :

oublier certaines instructions
ignorer des contraintes
produire des réponses incohérentes.

Notre première tentative a été d’écrire de plus gros prompts.

Ça n’a pas marché.

La solution a été l’inverse :

réduire la taille des documents et structurer le workflow.

Une feature = un dossier

La première règle que nous avons adoptée chez Ambris est très simple :

une fonctionnalité = un dossier dédié.

features/
└─ AIDD-0042_export_clients_csv/
   ├─ 00_input.md
   ├─ 10_spec_fonctionnelle.md
   └─ 20_spec_technique.md

Chaque étape du workflow produit un document.

Et surtout :

chaque étape n’utilise que le document précédent comme contexte.

Étape 1 : décrire la fonctionnalité en quelques lignes

Le point de départ est volontairement minimal.

Titre : Export CSV des clientsObjectif :
Permettre à un administrateur de télécharger un CSV contenant les clients.
Contraintes :
- pas de données sensibles
- filtres : date d'inscription, pays, statut actif
- CSV compatible Excel

5 à 10 lignes suffisent.

L’IA fera le reste.

Étape 2 : générer la spécification fonctionnelle

À partir de cette description, nous demandons à l’IA de produire une spec fonctionnelle structurée.

Prompt simplifié :

Tu es Product Owner.Lis features/{{FEATURE_ID}}/00_input.md
et génère une spécification fonctionnelle.Inclure :
- contexte
- parcours utilisateur
- règles métier
- critères d’acceptation (Gherkin)Si la fonctionnalité semble trop large,
propose un découpage en sous-features.

Le résultat est généralement très proche d’une spec produit classique.

Étape 3 : générer la spécification technique

Ensuite nous passons à la traduction technique.

Prompt simplifié :

Tu es architecte logiciel.À partir de la spécification fonctionnelle,
génère une spécification technique.Inclure :
- architecture
- composants
- interfaces
- validations
- gestion des erreurs

Ce document devient la référence pour l’implémentation.

Une décision importante : supprimer le plan d’implémentation

Au début, nous avions ajouté une étape intermédiaire :

spec technique → plan d’implémentation → code

L’idée semblait logique.

Mais dans la pratique, le plan devenait :

très long
difficile à relire
et surtout trop volumineux pour la fenêtre de contexte.

Nous avons donc pris une décision simple :

supprimer cette étape.

L’IA génère désormais le code directement à partir de la spec technique.

Étape 4 : génération du code

Avec le mode Agent, l’IA peut agir directement dans le projet.

Elle peut :

créer des fichiers
modifier plusieurs composants
proposer des diffs.

Prompt simplifié :

Tu es un agent de développement.Lis :
features/{{FEATURE_ID}}/20_spec_technique.mdImplémente la fonctionnalité dans /src.Contraintes :
- respecter les conventions du projet
- typage strict
- pas de dépendances externes

L’agent peut alors générer :

src/Service/CustomerExportCsvService.php
src/Controller/AdminCustomersExportCsvController.php
src/Helper/CsvBuilder.php

Chaque modification est proposée sous forme de diff validable.

Étape 5 : génération et exécution des tests

Une fois le code généré, nous demandons à l’IA de produire les tests.

Prompt simplifié :

Tu es un agent QA.La fonctionnalité {{FEATURE_ID}} vient d’être implémentée.1. génère les tests unitaires
2. couvre les cas nominaux et les cas limites
3. exécute les tests avec scripts/run_tests.sh

L’IA peut alors :

générer les tests PHPUnit
lancer la suite de tests
proposer des corrections si nécessaire.

Le workflow complet

Voici le pipeline que nous utilisons aujourd’hui.

Description courte
        ↓
Spec fonctionnelle
        ↓
Spec technique
        ↓
Agent IA : génération du code
        ↓
Agent IA : génération des tests
        ↓
Validation développeur

Le développeur reste dans la boucle à chaque étape.

Gérer les fonctionnalités trop grandes

Certaines features deviennent vite trop complexes.

Dans ce cas, l’IA propose un découpage :

AIDD-0045_import_clients
 ├─ validation
 ├─ stockage temporaire
 └─ reporting d'erreurs

Chaque sous-feature possède alors son propre workflow.

Cela permet :

de réduire la taille du contexte
d’améliorer la qualité des réponses
de paralléliser le travail.

Ce que cette approche change vraiment

Avant :

le développeur écrit le code
le développeur écrit les tests

Aujourd’hui :

le développeur décrit la feature
l’IA génère les specs
l’IA génère le code
l’IA génère les tests
le développeur valide

Le rôle du développeur évolue.

On passe progressivement de codeur à architecte et orchestrateur du workflow IA.

Ce que nous avons appris

Après plusieurs mois d’expérimentation chez Ambris, quelques principes ressortent.

Garder les descriptions très courtes

Une bonne feature description tient en moins de 10 lignes.

Une conversation IA par feature

Cela évite les mélanges de contexte.

Des specs structurées améliorent énormément la qualité du code généré

Éviter les documents trop longs

Ils consomment du contexte et dégradent la génération.

Conclusion

L’IA ne remplace pas les développeurs.

Mais elle transforme profondément la manière dont nous produisons du logiciel.

Chez Ambris, nous voyons l’IA comme :

un accélérateur
un copilote
et parfois un développeur junior très rapide.

Mais c’est toujours l’humain qui :

définit la direction
valide les choix
garantit la qualité.

Et dans ce nouveau modèle, la compétence la plus importante devient peut-être :

savoir orchestrer l’IA pour produire du code de qualité.