J'ai eu l'opportunité d'aller au TechReady de Nantes. Le sujet principal de la journée portait sur l'IA.
Je fais partie de ces développeurs à avis mitigés. Ni dans le camp "l'IA va tous nous remplacer", ni dans celui du "l'IA ne changera rien". Alors j'y ai été sans idée arrêtée sur ce que j'y trouverais.
Et j'ai été surprise.
Ce qu'on a vraiment entendu
Je m'attendais à des talks sur l'IA qui remplace le développeur. Sur les outils qui génèrent du code à la place de l'humain.
Ce n'est pas vraiment ce dont on a parlé.
On a parlé de ce que l'IA ne sait pas faire : comprendre un besoin métier. Cerner ce que le client veut vraiment derrière ce qu'il dit. Décider de l'architecture qui permettra au projet de vivre et de grandir.
Un des speakers l'a formulé ainsi : l'IA gère le macro et le micro, mais elle est inapte en compréhension du besoin.
Et les dirigeants présents à la table ronde sur le ROI ont confirmé quelque chose de contre-intuitif : les équipes qui utilisent l'IA ne livrent pas forcément plus vite. Elles livrent avec plus de qualité - plus de tests, moins de régressions, une production plus stable. Le temps gagné ne se traduit pas en vélocité brute. Il se reporte vers la rigueur.
La question évitée
Quand on automatise avec l'IA, une question se pose : si ce code est défectueux, qui est responsable ?
La réponse défendue par plusieurs speakers est claire : l'humain. Toujours.
L'IA ne peut pas être "coupable". Chaque commit livré reste sous la responsabilité du développeur qui l'a validé. Un des principes du Manifest IA développement présenté dans la journée le formule directement : "Ownership over delegation" - on reste propriétaire de ce qu'on livre, même quand l'IA en a généré une partie.
Ce qui implique de comprendre réellement ce qu'on pousse en production - pas d'accepter aveuglément ce que l'outil propose. "Understanding over acceptance" : l'IA nous rend aussi malins que stupides, selon qu'on comprend ou qu'on accepte.
La métaphore du photographe
Un intervenant a utilisé une comparaison intéressante.
À l'époque où la photographie était un art rare, le photographe maîtrisait tout : le positionnement, la lumière, les réglages techniques. Puis sont venus les appareils grand public. N'importe qui pouvait prendre une photo.
Le métier de photographe a changé. Mais il n'a pas disparu. Quand on veut des photos de qualité - un mariage, une campagne de communication, un portfolio - on fait toujours appel à un photographe.
Le parallèle avec notre métier est direct.
N'importe qui va pouvoir créer son site vitrine ou sa petite appli avec l'IA. Mais ça, c'était déjà le cas avec Shopify, WordPress, Bubble. L'IA va simplement encore accélérer ça.
La valeur d'un développeur n'a jamais été uniquement dans le fait d'écrire du code. Elle est dans la réflexion technique qui permet de coller à la vision du client, et de construire quelque chose qui peut vivre et évoluer avec ses besoins.
Ce que ça change (ou pas)
Ce que j'ai observé dans les retours d'expérience des équipes présentes, c'est un glissement de rôle déjà en cours.
Le dev passe moins de temps à coder mécaniquement, plus de temps sur la conception, les plans de tests, le refacto, la qualité. Il se déplace vers l'architecture de solution.
Et quelque chose m'a interpellée en voyant comment certaines équipes structurent leurs projets : une partie entière du code sert à définir ce que l'IA fera - ses limites, les pratiques à appliquer, les règles métier spécifiques. C'est du travail de conception, pas de l'automatisation aveugle.
Je pense que ce qui change, c'est le niveau d'abstraction. Depuis toujours, on cherche à dialoguer avec les machines dans un langage de plus en plus proche du nôtre : assembleur, puis C, puis Python. L'IA, c'est peut-être juste la prochaine étape de cette évolution.
Ce qui ne change pas : la rigueur, la méthode, la compréhension du problème avant de commencer à construire.
Un des manifestes présentés lors de la journée le formulait ainsi : "Outcome over Output" - construire du code, c'est simple. Construire un produit qui répond à un vrai besoin et qui tient dans le temps, ça ne l'est pas.
Écrire du code avec l'IA, n'importe qui peut le faire. Savoir ce qu'on écrit et pourquoi - c'est ça qui ne se délègue pas.
