Du DevOps à l’IA native : « Avec l’IA, les développeurs deviennent des managers d’agents »

Le Belge Patrick Debois est une figure clé du monde DevOps : c’est à lui qu’on attribue la paternité du terme, il est co-auteur du DevOps Handbook et l’initiateur des premiers DevOpsDays. Mais lors de sa conférence AI Native Development — rethinking our workflow, présentée au Tech.Rocks Summit, il a donné sa vision d’une nouvelle transformation.

Son positionnement est clair. Il ne se présente pas comme expert en IA, mais comme intégrateur. « Je ne suis évidemment pas un expert de l’IA. Ce que je sais faire, depuis des années, c’est connecter des choses, les intégrer. » Ce qu’il observe aujourd’hui l’amène à une conviction forte : l’IA n’est pas seulement un outil de productivité, c’est une refonte complète du workflow de développement.

Et pour lui, ce tournant ressemble beaucoup aux débuts du DevOps.

De producteur de code à manager d’agents, un basculement structurel

Patrick Debois pose d’emblée un constat qui n’aura échappé à personne : le rôle du développeur évolue. « Ils produisent peut-être plus de code… mais ils vont surtout devenir des managers d’agents. » En effet, la génération de code n’est plus le cœur du sujet. Ce qui devient critique, c’est la revue et l’orchestration du travail effectué par l’IA. Les agents peuvent produire dix, cinquante fichiers d’un coup. Le volume et la densité explosent, et les pratiques classiques ne suivent plus.

Il pointe, par exemple, les diffs (une commande Unix qui permet de comparer deux fichiers et d’en afficher les différences, ndlr) interminables : « La vue diff traditionnelle… c’est beaucoup de texte. Avec l’IA, ce ne sera pas trois lignes : ce sera énormément de texte. » Les discussions dans l’IDE ? « Encore plus de texte. Je n’ai pas le temps de lire ça ! »

Ce que propose Debois n’est pas de résumer l’IA avec une autre IA, mais de revoir la revue elle-même, avec des annotations intelligentes, des synthèses contextuelles, une visualisation graphique des changements, voire des formats plus inattendus comme NotebookLM, de Google, qui peut générer un podcast du travail accompli. « Le matin, on écoute le podcast et on sait ce que les agents ont fait. » Derrière ces exemples, l’idée centrale qui se démarque est celle d’un IDE qui devient un centre de gestion d’agents, pas seulement un éditeur.

L’IA rejoue les tensions du début du DevOps

Cette mutation rappelle à Patrick Debois un épisode fondateur. Au début du DevOps, les développeurs « jetaient le code par-dessus le mur », sans jamais l’avoir exploité eux-mêmes. L’Ops en héritait. Avec l’IA, dit-il, l’histoire se répète. « C’est exactement ce que l’on ressent avec l’IA. L’IA génère le code. On ne pense plus à la génération. Mais nous restons responsables quand il s’exécute, et quand il échoue. En ce sens, nous sommes tous Ops. »

L’expert déroule ensuite la logique classique du DevOps : aller vite, avoir de bons tests (« si on veut aller plus vite, il faut de meilleurs freins »), monitorer, observer l’inconnu, pratiquer le « chaos engineering ». Rien de tout cela ne disparaît avec l’IA. Au contraire, les systèmes étant générés à grande vitesse, la responsabilité humaine devient encore plus cruciale.

Il égratigne au passage l’idée qu’on pourrait « optimiser le ROI » en réduisant les effectifs grâce à l’IA : « Tous ceux qui pensent optimiser le ROI des développeurs en licenciant… non. Ils doivent être là quand les choses tournent mal. » L’IA accélère, mais le risque reste humain.

Du prompt aux spécifications : retour forcé aux bonnes pratiques

Le second mouvement décrit par Patrick Debois concerne la manière de diriger les agents. Il observe une transition nette, avec le passage d’un prompting éphémère à des spécifications persistantes. « Les gens commencent à écrire des spécifications. Ils créent un fichier markdown et disent à l’IA : « Lis ce fichier, et quand je le modifie, applique les changements. » » GitHub parle de intent-based coding : on ne détaille plus chaque étape, on décrit l’intention et l’agent implémente.

Ce changement fait remonter à la surface les fondamentaux du développement, comme la modularité, les découpages propres, la documentation à jour, les conventions de nommage, des tests fiables… « Si votre documentation n’est pas à jour, l’IA produira de mauvais résultats », analyse simplement Patrick Debois.

Il raconte qu’après une présentation de ce thème, une équipe lui a dit : « On devrait faire ça pour notre codebase », et sa réponse a fusé : « Pourquoi ne le faisiez-vous pas déjà ? » Il conclut en expliquant que l’IA ne remplace pas les bonnes pratiques, elle les rend à nouveau plus qu’indispensables.

Le product owner devient explorateur : prototyper sans attendre

L’un des constats les plus frappants concerne les product owners. Avec des outils comme Lovable, ils peuvent créer eux-mêmes des prototypes fonctionnels :
« Si je demandais ça à notre département IT, il faudrait un mois avant qu’un développeur me réponde. Maintenant, je peux le faire moi-même. »

En générant plusieurs variations (foncé, clair, version A, version B, etc.), ils apprennent plus rapidement ce qu’ils veulent. Le prototype devient un outil de réflexion, pas seulement d’illustration. « Et parce que le prototype est relativement peu coûteux, ils peuvent demander des options. »

Patrick Debois observe aussi l’arrivée d’agents parallèles capables d’explorer plusieurs chemins techniques simultanément, et l’émergence d’outils qui s’exécutent directement dans le cloud, en mode headless, pour multiplier les runs à bas coût.

Gérer les agents comme des équipes : un nouveau backlog

Pour orchestrer ce travail, les organisations commencent, selon lui, à créer de nouveaux backlogs dédiés : « Nous avons besoin d’un système de backlog pour les agents : « Agent, fais ceci ». »

Dans ce modèle, l’IDE n’est plus le lieu où l’on édite des fichiers . C’est le tableau de bord d’un ensemble d’agents, chacun avec une tâche, un périmètre, des permissions et des coûts associés. « L’IDE sert à gérer plusieurs agents simultanément et à examiner leurs différentes productions. »

Comme pour les humains, il faut bien sûr définir ce que les agents ont le droit de modifier : « IA, tu n’as pas le droit de toucher à nos tests », illustre Patrick Debois. Une nouvelle forme de gouvernance logicielle se dessine alors.

La connaissance devient infrastructure : vers la « ré-architecture continue »

Dernier pilier, la connaissance. Pour Patrick Debois, elle devient un flux en continu entre humains et agents. « L’apprentissage de connaissances devient une partie intégrante des agents de code. » La documentation doit être pensée aussi pour les agents : « Votre documentation est-elle optimisée pour être consommée par les agents ? C’est presque comme du SEO. »

Certains outils proposent déjà d’enregistrer automatiquement les décisions importantes au fil du développement : « Pendant que les agents codent avec nous… toutes ces connaissances sont sauvegardées dans les agents, par les agents. »

Et cette connaissance peut être partagée entre agents pour éviter qu’ils ne répètent les mêmes erreurs : « Si un agent apprend quelque chose, pourquoi ne transmettrait-il pas cette connaissance aux autres ? » Ce mécanisme l’amène à une vision plus large : « Ce n’est pas du continuous integration ou du continuous delivery. C’est du continuous re-architecting. »

Selon lui, la vraie question devient : à quel point une organisation est-elle capable de remplacer facilement un outil de code, un cloud, une technologie, une brique d’architecture ? L’IA rend cela possible, à condition de maîtriser les pratiques, les tests et la connaissance partagée. Il conclut avec une note d’humour : « Nous aurons toujours des moments « what the fuck », mais l’IA dira toujours que nous avons raison. »