TDD piloté par l'IA

« Ça marche » ne veut rien dire pour une IA

J'ai longtemps demandé à l'IA d'écrire une fonction, puis de la « corriger jusqu'à ce que ça marche ». Le problème : ça marche est une notion floue. L'IA croyait avoir fini, je relançais, un cas tombait à l'eau, je re-demandais, un autre cas cassait. On tournait en rond pendant vingt minutes.

Le déclic a été d'inverser l'ordre. Au lieu de décrire vaguement ce que je voulais, j'ai écrit le test d'abord. Le test dit en code, sans ambiguïté : « pour cette entrée, je veux exactement cette sortie ». Soudain, l'IA avait une cible nette. « Terminé » n'était plus une opinion, c'était une barre verte.

Le test, GPS de l'agent

Un agent IA autonome qui code sans tests, c'est une voiture sans GPS : il avance, mais il ne sait pas s'il se rapproche de la destination. Avec un test, l'agent a un signal clair à chaque tour : rouge (pas encore), vert (objectif atteint).

Mieux : l'agent peut lancer les tests lui-même, lire le message d'erreur, corriger, relancer : en boucle, sans vous. Vous n'écrivez plus le code, vous écrivez la définition de « réussi », et l'IA s'occupe du reste.

• Sans test : l'IA devine si c'est bon, vous vérifiez à la main, vous renvoyez du feedback
• Avec test : l'IA itère seule jusqu'au vert, vous ne validez qu'à la fin

Red, green, refactor : version IA

Le cycle TDD classique a trois temps, et chacun a son rôle quand on pilote une IA :

1. Red : vous (ou l'IA) écrivez un test qui échoue. Il décrit le comportement voulu avant qu'il existe
2. Green : l'IA écrit le code minimal pour faire passer le test. Rien de plus
3. Refactor : une fois vert, on nettoie le code sans changer le comportement. Le test reste vert, c'est le filet de sécurité

Prenons un cas concret : une fonction de calcul de prix avec remise. On écrit d'abord le test, qui décrit exactement les règles métier.

<?php
use PHPUnit\Framework\TestCase;

final class PriceTest extends TestCase
{
    public function test_sans_remise(): void
    {
        $this->assertSame(100.0, calculer_prix(100.0, 0));
    }

    public function test_remise_20_pourcent(): void
    {
        $this->assertSame(80.0, calculer_prix(100.0, 20));
    }

    public function test_remise_negative_interdite(): void
    {
        $this->expectException(InvalidArgumentException::class);
        calculer_prix(100.0, -5);
    }
}

Ce test est le cahier des charges. L'IA n'a plus à deviner : une remise de 0 ne change rien, 20 % retire un cinquième, et une remise négative doit lever une exception. On demande alors le code green.

<?php
function calculer_prix(float $base, float $remise): float
{
    if ($remise < 0 || $remise > 100) {
        throw new InvalidArgumentException('Remise invalide');
    }

    return round($base * (1 - $remise / 100), 2);
}

Le test empêche l'IA de casser l'existant

Le danger numéro un en codant avec l'IA : elle « améliore » une fonction et casse trois autres choses sans s'en rendre compte. C'est là que la suite de tests devient inestimable.

Quand l'IA modifie du code couvert par des tests, vous relancez la suite. Si un test au vert passe au rouge, vous savez immédiatement ce qui a régressé : avant même de déployer. C'est ce qu'on appelle un test de non-régression.

# Avant de faire confiance à une modif de l'IA
./vendor/bin/phpunit

# Sortie attendue
OK (3 tests, 3 assertions)

# Si l'IA a cassé quelque chose
FAILURES! Tests: 3, Failures: 1.
# -> on sait exactement quoi corriger avant de déployer