Pourquoi l’IA n’a pas tué les Dev et les DevOps
(et pourquoi c’est toujours une chance pour les entreprises d’en avoir !)
L’explosion de l’IA générative a particulièrement touché le monde du code : l’aspect répétitif, très structuré et facilement vérifiable de tout code (que ce soit du front – react, angular… –, du back – java, go, dotnet… – ou encore du code DevOps – terraform, ansible…), le volume d’exemples disponibles publiquement, la documentation technique des langages ainsi que la quantité de tutoriaux, d’articles de blogs et d’échanges dans les divers forums spécialisés facilitent grandement son apprentissage par des IA et son intégration dans des LLM.
Au point où le monde des développeurs a été rapidement en émoi dès les premiers mois de l’explosion de l’IA Générative, chacun allant de son post ou de sa vidéo pour expliquer pourquoi les développeurs allaient disparaître, ou, au contraire, pourquoi le monde aura toujours besoin de développeurs.
Avec deux ans de recul, on constate que le bilan est mitigé.
D’un côté, beaucoup d’entreprises se sont penchées sérieusement sur l’utilisation d’IA générative au sein de leurs équipes, mais pas forcément pour des besoins techniques : analyse de données au sein des équipes data, aide à la rédaction ou à l’analyse de documents, résumés de visios soporifiques, ou encore chatbots en veux-tu en voilà pour des besoins pas toujours justifiés (mais bon, il faut bien faire comme les petits copains, sous peine de se coller une image de dinosaure réac et poussiéreux et de se faire taxer d’immobilisme ou de manque de vision).
De l’autre, une inertie assez attendue, en particulier pour les boîtes les moins tech, et une approche plus mesurée, basée sur des use cases concrets, mais aussi sur l’attente des retours d’expérience des « early adopters ».
Côté Dev et DevOps, l’IA n’a pas radicalement transformé le quotidien de milliers de développeurs, mais est plutôt venue compléter leur travail, apportant avec elle son lot d’inconvénients :
- OUI, les outils d’aide à la complétion, à l’écriture de fonctions (GitHub Copilot, Cursor, Supermaven…), peuvent accélérer l’écriture de code, MAIS le processus de création de code bascule ainsi régulièrement sur de la revue de code et de la reprise de code pas toujours optimal (pas de factorisation ou de réutilisation de code par exemple), pas toujours performant ou à jour, voire même pas toujours correct : par principe, un LLM ne va pas comprendre ce qu’il écrit, et le développeur averti, distrait par les propositions affichées, en arrive souvent à passer plus de temps à tâcher de comprendre le code créé (et sa logique) et éventuellement débugger ce qu’a produit l’IA, quitte parfois à aller chercher le guillemet ou le point-virgule manquant, qu’à coder lui-même la fonction souhaitée ;
- OUI, des IA génératives spécifiquement entraînées sont capables de créer des sites web, ou des applications, sur la simple base de prompts décrivant le fonctionnel désiré (bolt, lovable…), c’est très efficace pour lancer rapidement un prototype ou pour avoir rapidement une base de travail dans un langage donné (même si on ne le maîtrise pas), MAIS dès qu’on veut affiner le résultat, on ouvre la boîte de Pandore : non correction des bugs demandés, régressions fonctionnelles (ex: on corrige un bug mais le comportement global ne correspond plus à la demande), explosion des coûts liés aux nombreuses itérations IA successives avec des contextes de code toujours grandissants ;
- OUI, les LLM permettent souvent de trouver beaucoup plus facilement une réponse possible (ou plausible) à une question spécifique qu’une recherche sur Internet, MAIS on perd aussi souvent l’intérêt des échanges et débats qu’on peut trouver sur certains forums à côté de la réponse, permettant de mieux la comprendre (et donc d’apprendre) et d’identifier potentiellement dans quels cas d’usage utiliser (ou non) cette solution ; de plus, dès qu’on pose des questions très spécifiques aux LLM, les hallucinations apparaissent rapidement, nous amenant à utiliser des options, syntaxes, structures qui n’existent tout simplement pas…
Pas de révolution donc, mais au final une optimisation des tâches à accomplir, un gain de productivité, particulièrement notable en début de projet, à condition de bien se servir de l’IA comme d’un outil d’accélération. Il n’en reste pas moins que le contenu généré par l’IA se doit toujours d’être contrôlé par un humain, et qu’un développeur ou un DevOps doit particulièrement bien connaître son sujet pour débusquer et corriger des erreurs, des problèmes de sécurité, des soucis de performance ou encore pour remettre en question des choix d’architecture logicielle proposés par l’IA qui ne sont pas toujours adaptés au contexte actuel.
Certains seraient alors tentés de supprimer des postes de développeurs ou de DevOps, grâce à ces gains de productivité, pour faire autant à budget moindre : ce serait passer à côté d’une formidable opportunité pour les entreprises de regagner du contrôle sur leurs services métier, mais aussi sur leurs coûts !
Tout d’abord, la doctrine du SaaS-First, rabâchée depuis des années, a depuis longtemps montré ses limites au niveau financier : certes, on n’a plus à se soucier de l’hébergement et du MCO de ses services métier, mais le coût global des applications SaaS explose (près de 10% d’augmentation en moyenne entre 2024 et 2025 à périmètre quasi-constant), après une évolution du TCO assez aléatoire lors du passage en SaaS lui-même, de nombreux éditeurs ayant profité de cette bascule pour masquer de fortes augmentation tarifaires. De plus, les modèles évolutifs de licencing SaaS ne sont pas toujours adaptés aux besoins réels de l’entreprise, ce qui peut engendrer du jour au lendemain des coûts supplémentaires difficilement anticipables ou soutenables. De nombreuses entreprises se sont ainsi senties « piégées » par ce passage au SaaS à marche forcée.
Dans ce contexte, l’optimisation et l’augmentation de productivité des équipes DevOps grâce à l’IA ayant pour conséquence directe de baisser les coûts globaux de gestion d’applications en interne, il peut devenir intéressant de réinternaliser certaines applications SaaS (dans la mesure où les éditeurs concernés supporteraient encore des versions auto-hébergées de leurs services en plus des versions en ligne).
Ensuite, de nombreuses entreprises ont des besoins applicatifs métier spécifiques, mais jusqu’à présent n’avaient pas les moyens de s’offrir une équipe de développeurs et de DevOps pour répondre à ces besoins. La conséquence logique était toujours la même : soit utiliser un logiciel existant, SaaS ou non, proche du besoin mais pas toujours adapté, et généralement pas ciblé sur le besoin précis, ou bien faire appel à un prestataire qui développerait et infogèrerait l’application. Dans ces deux cas, l’entreprise ne maîtrise pas ses assets logiciels, et toute évolution est soit impossible, soit potentiellement très onéreuse, ce qui amène de nombreuses organisations à travailler avec des outils métier peu adaptés, peu ergonomiques, ou encore fonctionnellement ou techniquement obsolètes.
Là encore, l’IA ouvre l’opportunité à une DSI (même petite) de mettre en place à coûts maîtrisés une petite équipe interne et ciblée de développeurs et de DevOps qui, grâce à une bonne utilisation de l’assistance fournie par les LLM, peut, à budget contrôlé, développer facilement et maintenir en interne des applications métier. L’aide des outils d’IA est même d’autant plus efficace que les applications sont spécifiques, voire développées dans une approche micro-services, avec un ensemble de composants unitaires, simples et efficaces, interagissant entre eux, et avec un design qui peut là encore permettre à la DSI d’optimiser ses coûts grâce à la conteneurisation. L’IA peut enfin participer à la création d’applications mieux sécurisées, domaine difficilement évaluable si on ne contrôle pas l’application en tant que telle.
Bien sûr, très souvent, un accompagnement est nécessaire lors de la mise en œuvre de cette cellule, afin de partir sur de bonnes bases, avec les bons réflexes et une bonne gouvernance. La présence d’au moins un spécialiste reste aussi nécessaire, ne serait-ce que pour avoir la vision globale, gérer les dépendances entre services, définir les flux internes, ou encore décider quelle résilience mettre en œuvre. Mais l’investissement dans la mise en place d’une telle équipe ne fait pas qu’optimiser les coûts de développement ou d’hébergement / MCO : il permet aussi in fine de proposer des outils métiers modernes à tous les collaborateurs, de répondre au mieux aux besoins métier exprimés par le terrain, de coller aux spécificités de l’entreprise, et d’être vecteur d’innovation en interne ou pour les clients.
Plus que jamais, garder le contrôle sur ses applications métier apporte une réelle valeur ajoutée, et cela est aujourd’hui rendu possible pour tous grâce au trio IA/Dev/DevOps !
