Garder les commandes quand l'IA code

Une bonne partie de mon site a été écrite par une IA. Aujourd'hui, elle écrit du code en production tous les jours, jusque dans les entreprises qui la conçoivent : ce n'est plus une hypothèse, c'est déjà la réalité. La question n'est plus de savoir si elle peut coder, mais comment s'adapter et garder les commandes.

Mon site répond mieux que n'importe quel discours. Je l'ai commencé sans connaître ni HTML ni CSS ; il est aujourd'hui bien plus abouti qu'à ses débuts, et il montre concrètement comment je travaille avec l'IA.

Comprendre avant de déléguer

Je ne délègue pas ce que je n'ai jamais compris, même un minimum. C'est ma première règle, et c'est par là que le site a commencé.

Au départ, je voulais apprendre le HTML et le CSS. J'ai dessiné une maquette dans Figma, puis je l'ai construite à la main, presque sans JavaScript. C'était lent, parfois maladroit, mais chaque ligne m'a montré comment une page tient debout. Reproduire une maquette quand on découvre le CSS est d'ailleurs une bonne leçon d'humilité : on réalise vite que même centrer proprement un élément demande de comprendre ce qui se passe dessous. Je n'en suis pas sorti expert, seulement capable de comprendre les bases et de m'en servir. C'était le but.

Pourquoi s'embêter, puisque l'IA aurait pondu tout ça en quelques minutes ? Parce qu'un outil qu'on ne comprend pas finit par nous tenir. Le jour où il casse, ou le jour où il faut expliquer un choix, on est démuni. Comprendre les fondations, même modestement, c'est ce qui permet ensuite de déléguer sans devenir l'otage de ce qu'on a délégué.

Le jugement d'abord, le code ensuite

Une fois les bases posées, l'IA devient un exécutant très rapide. Mais un exécutant a besoin de quelqu'un qui décide, et c'est là qu'est mon travail : avant et après le code, bien plus que pendant.

Quand j'ai voulu faire passer le site d'un projet d'étudiant à quelque chose de plus pro, je ne me suis pas contenté de lui demander « refais-moi un beau site ». J'ai posé une idée claire de ce que je voulais. Mais une IA livrée à elle-même part dans tous les sens ; il lui faut un cadre et un contexte clair. C'est là qu'intervient mon harnais IA, un sujet qui mérite son propre article : les consignes que je lui redonne à chaque fois pour qu'elle reste dans mes rails. Pas de framework, réutiliser les composants déjà présents, garder le site rapide et lisible. J'ai pesé le pour et le contre des options. L'IA a codé, j'ai testé, j'ai itéré, et je n'ai publié que quand le résultat correspondait à ce que je voulais. En revanche, la veille technique du site, ce pipeline qui publie une édition chaque semaine, je l'ai quasiment tout codée moi-même : je n'ai confié à l'IA que la régénération des pages HTML, la partie répétitive. L'automatisation, c'est mon terrain : c'est là que je veux continuer à explorer et à apprendre.

C'est peut-être ce que l'IA change le plus dans le métier. Faire quelque chose, ce n'est plus forcément l'écrire soi-même : c'est le concevoir, le cadrer, le décider, et savoir reconnaître quand c'est bon. Écrire le code compte moins, l'architecture et le jugement davantage.

Contrôler le résultat

Je ne relis pas chaque ligne de ce que produit l'IA. Le JavaScript de mon site, par exemple, je ne l'ai pas épluché. Ce que je sais, c'est quoi tester pour vérifier qu'un changement fonctionne et n'a rien cassé ailleurs. Mon contrôle porte sur le comportement, pas sur chaque instruction. Concrètement, je ne pars pas du contenu de la diff mais de ce qu'elle peut casser. Une retouche de CSS se juge à l'écran, pas que dans le code. Le vrai réflexe, c'est de savoir ce qu'un changement peut toucher ailleurs, y compris là où on ne s'y attend pas, et d'aller le vérifier plutôt que de tout relire.

Cela ne veut pas dire tout survoler. Le niveau de compréhension que je m'impose dépend du domaine. Sur le front, j'assume de déléguer et de ne pas tout maîtriser, ce n'est pas là que je concentre mon attention. Sur le DevOps et le cloud, c'est différent : là, même sans connaître le code par cœur, je veux comprendre ce que je fais et pourquoi, parce que c'est mon terrain et que je serai jugé dessus. Savoir où placer le curseur de sa compréhension, c'est déjà une décision.

Être honnête

La dernière règle est la plus simple, et la plus importante : assumer ce qui vient de moi comme ce qui vient de l'IA.

Ce n'est pas une question de posture. On ne peut défendre, expliquer et faire évoluer que ce qu'on a vraiment compris. Le code qu'on s'attribue sans l'avoir compris n'est pas un acquis, c'est une dette : tôt ou tard, il faut savoir ce qu'il fait et pourquoi.

Cette clarté est un atout, pas une contrainte : elle me dit en permanence ce que je maîtrise, ce que je délègue, et ce que je dois creuser. C'est la carte dont j'ai besoin pour avancer dans la bonne direction.

Là où je fais la différence

En un an, le métier de développeur a changé plus vite que jamais : l'IA écrit une partie du code, et ma valeur s'est déplacée ailleurs. Mon expertise se concentre maintenant sur l'ingénierie : comprendre le problème, le régler, et rester capable d'expliquer et de faire évoluer ce que je livre. Je m'appuie sur l'IA pour accélérer mon apprentissage et lui déléguer les tâches répétitives ou secondaires.

L'IA produit du code de mieux en mieux, et de plus en plus vite. Concentrer mon attention sur la façon de l'écrire plutôt que sur le problème à résoudre, ce serait perdre ma valeur. Ma différence est là : sur le problème.

Ce site est le premier endroit où je m'exerce, et tout y est visible. Le code est public, si tu veux voir : github.com/TuroTheReal/Portfolio.