“Je ne suis pas certain, c’est l’IA qui me l’a proposé.”
Comme tech lead, c’est probablement la pire phrase que j’ai entendue cette année.
Mettons les choses au clair : quand tu commit du code, que tu l’aies tapé toi-même ou qu’il ait été suggéré par un agent, c’est ton code. Il est à toi et tu l’assumes. Un point c’est tout.
On vit une époque exceptionnelle. Les outils sont plus puissants que jamais et notre métier, qu’on pensait jusqu’à tout récemment à l’abri de l’automatisation, est en train de se transformer radicalement grâce à l’IA générative et aux agents.
On ne mesure pas encore toute l’ampleur de cette mutation, mais une chose est sûre : la responsabilité du code, elle, reste entre nos mains.
Le principe de responsabilité Link to heading
On est responsable du code que l’on produit. Ce n’est pas une idée révolutionnaire. En fait, c’est un principe fondamental de l’ingénierie et du développement logiciel. Ça a toujours été comme ça, et il n’y a aucune raison que ça change avec l’arrivée des agents.
Le même principe s’applique dans tous les domaines où la sécurité, la fiabilité et la qualité sont cruciales. Par exemple, un ingénieur civil est responsable de la sécurité d’un pont, même s’il utilise des logiciels pour les calculs. Un médecin est responsable d’un diagnostic, même s’il utilise des outils d’IA pour l’aide à la décision.
Je ne sais pas si vous avez lu “Extreme Ownership” de Jocko Willink ? On peut être d’accord ou pas avec tout ce qu’il dit, mais l’idée de base est tout à fait pertinente : tu es responsable de tout ce qui se passe sous ton commandement, même si ça vient d’un subordonné, même si c’est fait à ton insu. Dans notre cas, l’agent est ce subordonné.
La mentalité à adopter est simple : pas d’excuse. Ce n’est pas “l’IA qui l’a fait”. L’agent est un assistant ou un collègue junior duquel tu es responsable.
Ok c’est bien beau tout ça en principe, mais je vois quand même trois pièges majeurs qui viennent compliquer les choses.
Piège numéro 1 : la compréhension et l’apprentissage Link to heading
Le métier de programmeur, ça s’apprend en écrivant du code. Il n’y a pas de raccourci. C’est comme ça. Qui plus est, l’humain en général apprend bien mieux en faisant qu’en regardant quelqu’un d’autre faire. Ça aussi, c’est un fait.
Quand on écrit du code soi-même, on est obligé de réfléchir à chaque ligne, à chaque choix. On se trompe, on corrige, on apprend. C’est un processus actif.
Avec un agent, on risque de devenir passif. On demande quelque chose, on reçoit une suggestion, on l’applique sans vraiment le comprendre. L’ownership qu’on gagne en écrivant le code soi-même n’est plus automatique. C’est le premier piège.
Piège numéro 2 : l’inflation du volume de code Link to heading
Les agents écrivent vite. Très vite. Bien utilisés, ils peuvent générer en quelques minutes beaucoup de code de qualité, souvent meilleur que ce qu’un humain pourrait produire en une heure. Ça a un côté génial, mais aussi un côté dangereux.
Plus de code écrit, c’est plus de code à comprendre, à maintenir, à tester. Au bout d’un moment, on se retrouve avec une base de code énorme, difficile à maîtriser parfaitement. Ce n’est pas nouveau problème, mais avec les agents, le rythme s’accélère. En d’autres mots, on risque de frapper le même mur, mais considérablement plus vite qu’avant. Dans ces circonstances, on peut avoir tendance à baisser notre garde, à faire confiance à l’agent et à abandonner le contrôle. C’est le deuxième piège.
Piège numéro 3 : la pression de livrer Link to heading
Il est clair que les agents nous font sauver du temps sur l’écriture du code. Ce faisant, ils créent un précédent où on s’attend à ce que tout aille de plus en plus vite. Il y a une pression, souvent de la part des décideurs, pour livrer rapidement.
“Si ça prend 10 fois moins de temps à écrire, pourquoi est-ce qu’on ne livre pas 10 fois plus de features ?”
Malheureusement, ces décideurs sont rarement les mieux placés pour décider de ce qui est “good enough”. C’est nous, comme professionnels du développement, qui devons garder le contrôle. Mais attention! Il ne s’agit pas non plus d’appliquer les freins et de ralentir le processus de développement à zéro. Il faut trouver le juste milieu entre rapidité et surqualité. Reste que la pression extérieure peut être forte pour laisser l’agent faire tout le travail sans surveillance. C’est le troisième piège.
Garder le contrôle Link to heading
Si on veut garder le contrôle, il est crucial de s’imposer une discipline. Relire le code généré ne suffit pas. Il faut le comprendre. Mieux encore : il faut être capable d’expliquer chaque choix fait par l’agent. Tant que ce n’est pas le cas, ton travail n’est pas terminé.
Voici mes stratégies pratiques pour garder le contrôle :
- Profiter de l’agent pour apprendre. Par exemple, lui demander “explique-moi pourquoi tu choisis cette approche”. Ça aide à comprendre le raisonnement derrière le code.
- Rejeter le code que tu ne comprends pas. Si l’agent produit du code confus ou obscur, demande-lui de le réécrire d’une manière plus claire.
- Toujours poser la question simple : “Suis-je prêt à défendre ça en revue de code ?”. Parce que vous savez quoi ? Ça va arriver.
- Écrire la documentation manuellement. Personne n’aime ça, et c’est tentant de laisser l’agent le faire. Mais écrire la doc soi-même force à reformuler, à expliquer, donc à comprendre. C’est du travail en plus, mais un investissement qui garantit que tu maîtrises ton code.
Il ne faut pas voir ces stratégies comme des trucs mais bien comme des conditions pour rester en contrôle et assumer pleinement son rôle de développeur responsable.
Conclusion Link to heading
En fin de compte, le message est très simple : à partir de maintenant, c’est tolérance zéro pour l’absence d’ownership.
La transition des agents est déjà en marche. C’est inévitable. Mais ce n’est pas négatif. Au contraire.
Avant, écrire du code coûtait cher, en temps comme en énergie. On n’avait pas le luxe d’aller au-delà du “good enough”. Aujourd’hui, demander une autre version ou tester une approche différente ne coûte presque rien.
Alors pourquoi ne pas en profiter pour :
- Être intransigeant sur la lisibilité et la clarté.
- Refuser les compromis sur la qualité.
- Explorer plusieurs alternatives avant de choisir la meilleure.
- Écrire de meilleurs tests et une documentation vraiment utile.
C’est ça le vrai changement de paradigme : les agents ne sont pas une raison pour baisser nos standards. Au contraire! C’est une opportunité pour les rehausser.
Donc à partir de maintenant, pas d’excuse, de l’ownership.