L'IA n'est pas un générateur de code, c'est un partenaire de réflexion

Après plus de 20 ans de développement, je ne pensais pas qu'un assistant IA allait encore me faire évoluer dans ma façon de concevoir du code.

Au début, je l'utilisais comme beaucoup : « Écris-moi cette classe », « Fais-moi ce test », « Optimise cette méthode ». C'était séduisant.

Puis je me suis surpris quelques fois à accepter certaines propositions presque sans les challenger. Je gagnais du temps, mais j'avais aussi l'impression de moins réfléchir. Et ça me dérangeait.

Décrire le problème plutôt que demander une solution

Il y a quelques mois, je travaillais sur une règle de validation autour des limites de risque d'une contrepartie. Au lieu de demander directement une implémentation, j'ai simplement décrit le contexte métier : les règles à respecter, les contraintes, les cas particuliers.

Sa première proposition n'était pas ce que j'aurais mis en production. Mais son raisonnement m'a vraiment intéressé. Il proposait une approche différente que je n'aurais pas pensé utiliser. Ce n'était pas la bonne réponse, mais c'était une réponse suffisamment argumentée pour mériter qu'on la discute.

C'est à ce moment-là que la conversation devient intéressante.

 décrire le      première       questionner       garder ou
 problème   ───► proposition ─► le raisonnement ─► rejeter,
 (contexte,      de l'IA         (pourquoi,         en le
 contraintes)                    et si, comment)    justifiant
      ▲                                                 │
      └─────────────── itérer si la réponse ◄───────────┘
                        ne tient pas

Les questions qui font la différence

J'ai commencé à lui poser des questions, plutôt qu'à simplement accepter ou rejeter :

Pourquoi avoir choisi cette approche plutôt qu'une autre ?
Que se passe-t-il si les règles métier évoluent dans six mois ?
Comment tester cette logique si un service externe devient indisponible ?
Est-ce qu'on est en train de sur-concevoir le problème ?

Parfois, ses réponses me font complètement revoir mon approche. Parfois c'est l'inverse : il propose une architecture beaucoup trop sophistiquée pour le besoin réel. L'important n'est pas d'accepter sa réponse, mais de comprendre pourquoi je la garde, ou pourquoi je la rejette.

C'est probablement ce qui m'a le plus marqué dans cette pratique.

Ce que ça change dans ma façon de relire du code

Ce même réflexe a fini par contaminer ma façon de faire des revues de code, IA ou pas. Face à une pull request, je me surprends maintenant à poser les mêmes questions à un développeur humain qu'à un assistant : pourquoi cette approche, que se passe-t-il si le contexte change, a-t-on vérifié le cas limite. Ce n'est pas un hasard : challenger un raisonnement, qu'il vienne d'un modèle ou d'un collègue, repose sur la même discipline. L'IA m'a servi d'entraînement à froid, sans enjeu relationnel, pour une compétence que j'utilise ensuite avec des humains.

Un partenaire, pas un exécutant

Aujourd'hui, je vois l'IA comme un partenaire de réflexion, pas comme un générateur de code. Si une conversation ne m'a pas amené à remettre en question un choix de conception, j'ai souvent l'impression d'être passé à côté de quelque chose.

Avec le recul, j'ai réalisé quelque chose : la qualité des réponses dépend bien plus des questions que je pose que du modèle utilisé. Le modèle fixe le potentiel maximum, mais c'est notre posture d'ingénieur qui permet de l'atteindre. Un développeur qui accepte la première réponse sans la challenger n'obtiendra jamais ce que peut donner le même outil entre les mains de quelqu'un qui insiste pour comprendre le pourquoi avant le quoi.