Cinq décisions d'ingénierie à prendre avant de générer du code avec l'IA

Un ingénieur prend des décisions soit dans le code, soit avant lui. Si la première question est posée directement à l'IA, le résultat fonctionnera, mais son coût grimpera déjà à la deuxième mise en production.

Vibe coding vs travail d'ingénierie

Le vibe coding est un processus où l'on décrit un résultat, on demande une modification en fonction de ce qu'on observe, et dès que l'écran fonctionne, on s'arrête. Le travail d'ingénierie avec l'IA intègre en plus les contraintes du système existant, les changements admissibles, les conditions d'échec et les moyens de vérification. Du code peut être généré dans les deux cas. La différence réside dans les décisions prises consciemment.

Ce ne sont pas des niveaux d'expérience — un développeur débutant peut travailler selon la seconde approche, un expert selon la première. Ce qui compte, c'est l'expérience transformée en compréhension des dépendances. Quand on a déjà dû rollback une version ou démêler un enregistrement concurrent en base de données, de nouvelles questions surgissent naturellement dans une nouvelle tâche — avant le code et avant le premier incident.

Pour un prototype, une vérification visuelle peut suffire. Pour un service avec des utilisateurs réels, la demande « ajoute encore une fonctionnalité » modifie déjà un système en production, et son coût ne se résume pas au temps de génération.

Cinq décisions avant la première ligne de code

1. Intégrations : définir la frontière du contrat externe

Sur un produit en production, cela se traduit souvent par trois services distincts : A récupère les données du fournisseur, B implémente la règle métier, C affiche le résultat. Si le format externe s'est infiltré dans les trois composants, un nouveau fournisseur implique de modifier A, B et C simultanément. Si A convertit les données vers un contrat interne, un nouveau fournisseur se traduit par un nouvel adaptateur, sans toucher à B ni à C.

Exemple : un catalogue de jeux provenant de deux sources. La première décrit un jeu comme `{id, name}`, la seconde comme `{code, title}`. La mauvaise approche consiste à faire connaître les deux formats aux consommateurs, qui choisissent le champ selon le type de source. Chaque nouveau fournisseur ajoute une nouvelle branche dans chaque fonction, et au bout d'un an, plus personne ne sait combien d'endroits doivent être modifiés. La bonne approche : les adaptateurs convertissent vers un contrat commun `{key, title}`, les consommateurs ne connaissent pas le fournisseur. Ajouter une nouvelle source ne nécessite pas de tester l'ensemble du système en régression.

2. Plateforme multimarque : définir les frontières de la variabilité

Chaque marque de la plateforme était un produit distinct, pas une copie d'un template avec un autre logo. Chacune avait ses propres licences, marchés, équipes produit et calendriers de mise en production. Il fallait faire évoluer l'ensemble sur une base de code unique, en préservant les différences réelles.

Le modèle initial semblait suffisant : un thème de base, redéfini pour une marque donnée. Les redéfinitions ont débordé le cadre des couleurs. Une même tâche était résolue différemment à plusieurs endroits, les particularités locales se sont accumulées, la cohérence du style s'est perdue.

Il a fallu migrer vers des mixins SCSS, dont les chemins étaient résolus dans le contexte de la marque au moment du build. Cette migration, sur des produits déjà en production, s'est révélée plus coûteuse que de choisir directement le bon modèle dès le départ.

3–5. Opérations concurrentes, topologie et garanties de livraison

Un rechargement de solde avec deux tentatives simultanées exige une idempotence et des frontières transactionnelles claires. Un message de chat après un redémarrage exige une topologie de stockage et de récupération. La suppression de données anciennes avec une tâche en retard exige une durée de vie définie et une réexécution sécurisée. Une mise en production prête nécessite des signaux de scénario métier et des conditions d'arrêt.

L'expérience ne se traduit pas en points dans un prompt, mais en questions concrètes dans la formulation du besoin. La longueur du prompt en soi n'apporte rien. Si la tâche est locale et réversible, la formulation peut rester courte. Si elle touche un contrat commun, un solde ou des droits d'accès, quelques clarifications avant l'implémentation changent le modèle de données, la transaction et le scénario de test.