Développement fondé sur des données probantes
La discipline manquante dans l'ingénierie assistée par l'IA
De nombreuses équipes ont répété une histoire commune. Ils ont adopté les outils de codage de l'IA, la vitesse a explosé, puis trois semaines plus tard, ils déboguent quelque chose que l'IA a « définitivement testé ».
L'IA n'a pas de problème de génération. Il y a un problème de preuves.
La boucle
Le modèle qui fonctionne réellement n'est pas compliqué. C'est juste discipliné.
L'idée principale : documenter ce que vous êtes sur le point de faire, prouver que l'état actuel ne le satisfait pas, capturer la ligne de base, implémenter, prouver que cela fonctionne, capturer le résultat et vérifier que rien d'autre n'est cassé.
| Phase | Ce qui se passe | Pourquoi c'est important |
|---|---|---|
| Document | Écrivez à quoi ressemble « fait » avant l'implémentation. | Force la compréhension avant le début du codage, pas après. |
| Test : échec | Définissez et exécutez des tests qui prouvent que l'écart existe. | Confirme que vous testez le comportement, pas des hypothèses. |
| Capture : avant | Enregistrez l'état actuel avant de toucher à l'implémentation. | Établit la ligne de base nécessaire à une revue crédible. |
| Mettre en oeuvre | Appliquez le changement avec l'aide de l'IA sous contraintes claires. | L'exécution reste rapide pendant que les humains gardent la barre. |
| Test : réussite | Exécutez les tests ciblés et confirmez que le comportement passe maintenant. | Valide que le changement résout exactement les critères d'acceptation. |
| Capture : après | Collectez les mêmes artefacts après le changement. | Permet une comparaison avant/après directe. |
| Vérifier | Auditez sécurité, accessibilité, performance, documentation et dérive. | Attrape les modes de défaillance que les tests seuls ratent. |
| Revue | Le relecteur humain accepte ou rejette sur la base des preuves. | Maintient la responsabilité chez les ingénieurs, pas chez les prompts. |
"Avant" les preuves sont irréversibles - en pratique
Si vous ignorez la capture de l'état avant et passez directement à la mise en oeuvre, vous pouvez techniquement encore le reconstruire plus tard.
En pratique, presque personne ne le fait. C'est pourquoi l'absence de preuve avant est traitée comme une condition de remise à zéro dans une boucle disciplinée.
Les dix dimensions de l'audit
| Dimension | Ce que cela détecte |
|---|---|
| Build | Compilation, lint et intégrité de la suite de tests |
| Télémétrie | PII dans les journaux, charges utiles non sûres et fuites de données |
| Accessibilité | Repères, navigation clavier et hiérarchie des titres |
| Sécurité | Secrets, risques d'injection et vulnérabilités de dépendances |
| Performance | Chemins N+1, boucles non bornées et fuites mémoire |
| Documentation | Dérive entre la spécification et l'implémentation |
| Couverture de tests | Changements de comportement sans tests correspondants |
| Dette TODO | Suivis sautés et espaces réservés non résolus |
| Gestion des erreurs | Erreurs avalées et détails internes divulgués |
| Verbosité IA | Commentaires redondants et abstractions inutiles |
Le fardeau de la preuve dans les pull requests
Une pull request est une mémoire organisationnelle de long terme. Si les exécutions de tests, les captures de preuves et les audits manquent, le relecteur reçoit des affirmations au lieu de faits.
Les PR fondées sur des preuves incluent des artefacts, pas des promesses : sorties, captures d'écran, diffs et résumés d'audit.
Exemples de preuves par domaine
| Domaine | Preuve avant | Preuve après |
|---|---|---|
| Point de terminaison API | Réponse curl avec mauvais statut | Réponse curl avec statut et schéma attendus |
| Migration de base de données | Requête avant migration | Requête montrant les nouvelles colonnes et les valeurs remplies |
| Infrastructure | Sortie du plan actuel | Plan souhaité et sortie d'application |
| Performance | Référence de base | Delta de benchmark après optimisation |
| Correctif de sécurité | Résultat du scanner avec alerte | Rapport du scanner propre |
Commencer demain
- Ajoutez une section Avant/Après obligatoire à votre modèle de PR.
- Définissez ce que les tests doivent prouver avant les prompts d'implémentation.
- Exprimez le "terminé" en termes de preuves, pas de confiance.
- Auditez d'abord les fichiers modifiés, puis élargissez la portée si nécessaire.
- Traitez l'absence de preuves comme un travail incomplet, pas comme une dérogation.
Références
- Kent Beck (2025) Codage augmenté : au-delà des vibrations
- ThoughtWorks (2025) Développement Test-First assisté par l'IA
- METR (2025) Les outils d'IA ont rendu les développeurs expérimentés 19 % plus lents
- Addy Osmani (2026) L'IA écrit le code plus rapidement. Votre travail consiste encore à prouver que cela fonctionne.
- Microsoft.NET (2026) Dix mois avec Copilot Coding Agent dans dotnet/runtime