L'IA dans le CI/CD

Les volets précédents de cette série ont décrit un déplacement : l'IA accélère la production de code, et le métier glisse vers spécifier, vérifier, décider où l'humain garde la main. Le pipeline d'intégration et de livraison continues — le CI/CD — est l'endroit où ce déplacement devient le plus concret. L'IA s'y invite à presque chaque étape : elle rédige des tests, résume un diff, commente une pull request, signale une vulnérabilité. Mais il reste un endroit où elle n'appuie pas sur le bouton : le passage en production. La bonne question n'est pas « l'IA peut-elle automatiser le pipeline ? », mais « où propose-t-elle, et où l'humain doit-il garder la porte ? »

Ce que l'IA sait vraiment accélérer dans le pipeline

Commençons par le côté encourageant, car il est réel. Le rapport 2024 Accelerate State of DevOps de DORA (Google Cloud) chiffre l'apport de l'IA sur la qualité en amont : une hausse de 25 % de l'adoption de l'IA est associée à une amélioration estimée de 3,4 % de la qualité du code et de 3,1 % de la vitesse de revue de code — sans parler de la documentation, qui progresse davantage. Là où l'IA excelle, c'est sur le travail d'assistance : produire un premier jet, éclairer, résumer.

Concrètement, l'IA intervient tout au long du pipeline (Fig. 1). Au moment du commit, elle génère un résumé de diff lisible. Quand un build échoue, elle explique le message d'erreur en langage clair. Sur les tests, elle propose des brouillons ou complète une couverture existante. En revue de pull request, elle commente le code et suggère des correctifs. Et sur le plan sécurité, elle signale des motifs suspects et des vulnérabilités possibles. À chaque étape, le dénominateur commun est le même : elle produit une proposition, pas une décision.

Ce qui reste, obstinément, une décision humaine

Deux nœuds du pipeline ne se délèguent pas : le merge, qui décide de ce qui entre dans la branche, et le déploiement, qui décide de ce qui part en production. Ce ne sont pas des étapes comme les autres : ce sont des actions à fort impact, difficiles à défaire. Les recommandations de sécurité OWASP pour les applications à base de LLM le formulent comme une règle d'ingénierie. Face au risque d'« agence excessive » (LLM06) — quand un système déclenche des actions dommageables à partir d'une sortie inattendue ou manipulée —, la parade est explicite : « recourir à un contrôle humain dans la boucle pour exiger qu'un humain approuve les actions à fort impact avant qu'elles ne soient entreprises ». Et l'autorisation doit être vérifiée en aval, « plutôt que de compter sur un LLM pour décider si une action est permise ».

Le même principe se retrouve, avec force de loi, dans le règlement européen sur l'IA. Son article 14 impose que les systèmes à haut risque puissent être « effectivement supervisés par des personnes physiques ». La personne qui supervise doit pouvoir « ne pas utiliser le système, ou ignorer, passer outre ou inverser sa sortie », et « interrompre le système au moyen d'un bouton d'arrêt ou d'une procédure similaire permettant un arrêt en toute sécurité ». Autrement dit : ignorer, annuler, arrêter. C'est exactement la posture attendue devant un merge ou un déploiement suggéré par l'outil — l'humain garde la porte, et la porte a un verrou (Fig. 2).

Faux positifs, faux négatifs : la revue IA n'est pas un verdict

Une revue automatisée se trompe dans les deux sens. Elle produit des faux positifs — elle signale un problème qui n'en est pas, et fait perdre du temps — et des faux négatifs, plus dangereux : elle laisse passer une vraie faille en restant silencieuse. Ce n'est pas un défaut réparable un jour : un modèle génératif produit, par construction, un contenu parfois énoncé avec assurance mais erroné — ce que le profil IA générative du NIST nomme confabulation. Sur du code, cela veut dire qu'un correctif suggéré peut sembler juste et introduire une régression. D'où la nécessité d'un arbitrage humain sur chaque signalement.

Le rapport DORA 2024 ajoute une nuance qu'il faut entendre. Si l'IA améliore la qualité perçue et la vitesse de revue, ses effets sur la livraison elle-même ne sont pas magiques : une hausse de l'adoption s'accompagne d'une baisse estimée de la capacité de livraison (throughput) d'environ 1,5 % et de la stabilité de livraison d'environ 7,2 %. Le rapport le résume sans détour : « l'IA ne semble pas être une panacée ». Autre signal : 39 % des répondants déclarent avoir peu ou pas confiance dans le code généré par l'IA. Ces chiffres ne disqualifient pas l'outil — ils rappellent que produire plus vite en amont ne fiabilise pas mécaniquement ce qui part en production. Cette prudence prolonge d'ailleurs directement les nœuds de vérification humains déjà posés dans cette série : le déploiement en est le nœud le plus dur.

Ce que cela change pour l'équipe

Le pipeline outillé par l'IA ne supprime pas le rôle de l'équipe : il le déplace vers le haut. Moins de temps passé à rédiger un test trivial ou à décortiquer un log ; plus de temps consacré à juger, arbitrer, décider ce qui mérite d'entrer dans la branche et de partir en production. La valeur ne se trouve plus dans la frappe, mais dans le discernement. C'est aussi pour cela que la question du contrôle change de nature quand un outil ne se contente plus de suggérer mais commence à agir sur la machine : plus une IA gagne en autonomie, plus la porte humaine devant la production doit être explicite. Le fil de cette série reste le même, depuis « écrivons-nous encore du code ? » : l'humain ne disparaît pas du pipeline, il en garde les portes décisives.