Claude Code et Codex vont-ils rendre les ingénieurs infra et réseau inutiles ? — La réalité que l'IA impose à l'exploitation

« J'ai demande à Claude Code de m'ecrire du Terraform pour lancer une instance EC2, et 30 secondes plus tard j'avais le code. Ça veut dire que le métier d'ingénieur infra va disparaître, non ? »

Beaucoup de gens se posent cette question. Les outils de codage IA progressent à une vitesse impressionnante, et dans le domaine de l'infrastructure la génération de code, la création de fichiers de configuration et l'analyse de logs sont devenues beaucoup plus rapides. Le Codex (agent de codage) publie par OpenAI en 2025 est lui aussi particulièrement à l'aise avec le code d'infrastructure.

Alors, les ingénieurs infra et réseau sont-ils vraiment en train de devenir inutiles ?

La réponse courte : ce n'est pas un « remplacement » mais un « changement de rôle » qui est en train de se produire. Dans cet article, nous allons préciser, pour le domaine de l'infrastructure, ce que l'IA sait bien faire et ce qu'elle ne sait pas faire, puis detailler la stratégie concrète à adopter.

1. Ce qui se passe aujourd'hui — l'évolution des outils de codage IA

Commençons par poser le décor : qu'est-ce que les outils de codage IA savent réellement faire dans le domaine de l'infrastructure ?

Les principaux outils et leur couverture infra

Le point remarquable : ces outils ne se contentent plus de compléter du code, ils fonctionnent comme de véritables « agents ». Claude Code lit et écrit les fichiers, exécute des commandes, et Codex va jusqu'à vérifier le résultat dans un sandbox.

Le périmètre de leurs capacités s'élargit très vite

Fin 2024, un outil IA se limitait en gros à « générer un squelette Terraform ». Entre 2025 et 2026, il est désormais capable de :

• Lire un code d'infrastructure existant et y repérer les problèmes de sécurité
• Partant de « je veux déployer cette application sur AWS », proposer d'un coup une architecture VPC, sous-réseaux, SG, ALB, ECS/EKS
• Analyser les logs d'erreurs de production et proposer des causes probables avec leurs remediations
• Construire de zéro un pipeline CI/CD
• Générer et corriger des manifests Kubernetes ou des Helm charts

Vu cette progression, il n'est pas etonnant de se dire « on n'a plus besoin d'ingénieurs infra ». Mais ce n'est qu'un côté de la medaille.

2. Les tâches infra que l'IA sait faire

L'IA est particulièrement forte dès qu'une tâche peut s'exprimer en code, suit des motifs reconnaissables et repose sur du texte.

1. Génération d'Infrastructure as Code (IaC)

Terraform, CloudFormation, Pulumi, Ansible, Chef — la génération de code pour ces outils IaC est le terrain de jeu favori de l'IA.

2. Génération et optimisation des fichiers de configuration

nginx.conf, apache.conf, règles iptables/nftables, unités systemd — l'IA excelle aussi dans ces fichiers. Si vous lui demandez « écris-moi une configuration nginx en reverse proxy avec SSL pour cette application », elle produit une configuration conforme aux bonnes pratiques.

3. Analyse de logs et détection d'anomalies

Extraire des motifs d'un volume massif de logs est un domaine où l'IA est particulièrement à son aise.

• Synthèse de syslog, journald, CloudWatch Logs et autres logs textuels
• Classification et comptage des motifs d'erreurs
• Réponse instantanée à des questions comme « quelles erreurs explosent sur la dernière heure ? »
• Proposition de causes probables et de remediations à partir des logs

4. Génération automatique de documentation et de procédures

L'IA peut lire un code d'infrastructure existant et produire automatiquement une description d'architecture, un manuel d'exploitation ou un brouillon de procédure de reprise. C'est précisément le type de tâche que les ingénieurs infra detestent faire (mais qui reste essentielle).

5. Vérifications de sécurité

Détection des politiques IAM trop permissives, vérification des règles de security group, conformité d'un code Terraform au CIS Benchmark : les revues de sécurité routinières peuvent déjà être assistees par l'IA.

3. Les tâches infra que l'IA ne peut pas faire

C'est le cœur du sujet. Sans une vision claire des limites de l'IA, on court vers le pire scenario : « on confie tout à l'IA » → incident majeur.

1. Les tâches physiques

Évidence : l'IA ne peut pas toucher physiquement à quoi que ce soit.

• Installation et câblage du matériel dans les baies
• Remplacement d'un disque HDD/SSD défectueux
• Configuration et remplacement physiques des équipements réseau (routeurs, switchs, pare-feux)
• Contrôle d'accès et sécurité physique des centres de données

« Avec le cloud, les tâches physiques vont disparaître, non ? » On pourrait le croire, mais environ 60% des entreprises japonaises conservent une part d'on-premise (étude IDC Japan). L'infrastructure physique ne va pas disparaître du jour au lendemain.

2. Les décisions métier en cas d'incident

Quand une panne frappe la production, le plus important est la décision métier : que faut-il sauver en priorité ?

• « La base est corrompue. Restaurer depuis la sauvegarde fait perdre les 2 dernières heures. On restauré où on tente une réparation ? »
• « Le service À et le service B sont tous deux à terre. Les ressources sont limitées, on relève lequel en premier ? »
• « Soupcon d'intrusion. On coupe tout pour enquêter où on continue à tourner en enquetant ? »

Ces décisions exigent non seulement des connaissances techniques, mais aussi de peser l'impact business, les engagements client (SLA), les risques juridiques, et la coordination avec la direction — autant d'éléments qu'on ne peut pas confier à l'IA. Celle-ci peut « proposer des options », mais pas « prendre une décision engageant la responsabilité ».

3. Les schémas de panne inconnus

L'IA est forte sur ce qu'elle a déjà vu dans ses données d'entraînement, mais faible face à une panne que personne n'a encore rencontrée.

• Un bug non documente côté fournisseur cloud
• Une panne composite sur plusieurs systèmes (réseau + DNS + application qui décroche en même temps)
• Une défaillance intermittente due au vieillissement du matériel

Dans ces situations, le « flair » d'un ingénieur expérimenté — c'est-à-dire sa capacité à raisonner par analogie avec des cas passés — fait toute la différence.

4. La responsabilité finale en matière de sécurité

Même si l'IA affirme « cette configuration est sécurisée », ce n'est pas une garantie. En cas d'incident, la responsabilité juridique et éthique revient aux humains, pas à l'IA.

• Déclaration et gestion d'une fuite de données personnelles auprès des autorités competentes
• Enquête forensique et préservation des preuves
• Définition des mesures correctives et reporting à la direction
• Notification et communication aux clients

5. Gestion et négociation avec les fournisseurs

Fournisseurs cloud, opérateurs de centres de données, FAI, prestataires de sécurité — la mission d'un ingénieur infra comprend beaucoup de relations extérieures. Negocier les conditions contractuelles, s'entendre sur les SLA, coordonner la réponse aux incidents : c'est un terrain purement humain, où l'IA n'a pas sa place.

4. Impact sur les ingénieurs réseau

L'ingénierie réseau occupe une place un peu particulière dans l'infrastructure. Regardons en détail l'impact de l'IA sur ce métier.

Ce que l'IA sait automatiser en réseau

Ce que l'IA gère mal en réseau

• Conception et mise en œuvre du câblage physique : plan d'etage, cheminements de câbles, organisation des baies
• Études radio et conception Wi-Fi : nécessitent une inspection physique sur site, analyse des matériaux des murs, identification des sources d'interference
• Diagnostic des pannes de couche 1 : câble coupe, port defaillant, niveau de signal optique dégrade — vérification physique obligatoire
• Négociation avec les opérateurs : nouveaux liens, changements de débit, ajustements des configurations redondantes
• Migrations réseau de grande ampleur : planification et exécution de la migration de centaines d'équipements, avec minimisation du downtime

Parce que le réseau dépend fortement de la couche physique, il est plus difficile à remplacer complètement par l'IA que l'infrastructure serveur. Cela dit, l'IA reste très utile pour accélérer la génération des configurations et le diagnostic.

5. Comment ça change réellement sur le terrain

Au-delà de la théorie, voyons comment l'IA est réellement utilisée sur le terrain à travers quelques scénarios.

Scenario 1 : accélération du développement IaC

Dans une startup, les ingénieurs infra utilisent Claude Code pour générer leur code Terraform. Ce qui prenait avant 30 minutes à une heure pour une seule ressource AWS se fait désormais en 5 à 10 minutes — l'humain décrit le besoin, l'IA généré, l'humain relit et corrige.

Point crucial : le code généré par l'IA n'est jamais applique directement en production. Un humain le revoit systématiquement et ajuste la configuration en tenant compte de la sécurité et de l'optimisation des coûts.

Scenario 2 : soutien en phase initiale d'incident

Quand un incident tombe en production, l'IA analyse d'abord les logs pour isoler les causes probables, puis l'humain prend la décision finale et procède à la remédiation. Une répartition nette des rôles.

• Avant : 30 minutes à 1 heure pour identifier la cause en lisant les logs à l'œil
• Après : l'IA sort 3 hypothèses en 5 minutes, l'humain vérifie et intervient

Le MTTR (temps moyen de rétablissement) baisse, mais un nouveau risque apparaît : « prendre à la lettre l'analyse de l'IA et faire une mauvaise remédiation ». La décision finale doit rester entre les mains d'un ingénieur expérimenté.

Scenario 3 : accélération de la montée en compétence des juniors

On a longtemps dit « en infra, sans expérience on ne peut rien faire ». L'IA adoucit considérablement cette courbe d'apprentissage.

• « Explique-moi ce code Terraform ligne par ligne » → l'IA déroulé chaque ligne
• « Pourquoi faut-il restreindre le port 22 dans ce security group ? » → l'IA explique le contexte et les raisons
• « Je ne sais pas lire ce log d'erreur » → l'IA donne la structure et pointe les passages importants

Ce n'est pas « on n'a plus besoin d'ingénieurs », c'est « les ingénieurs montent en compétence plus vite ».

Scenario 4 : l'équipe infra d'une seule personne

Des opérations qui exigeaient 3 à 5 personnes peuvent désormais tourner à 1 ou 2 grâce à l'IA. Les effectifs se réduisent, mais ceux qui restent doivent avoir des compétences et un discernement plus pointus.

6. Comment survivre en tant qu'ingénieur infra à l'ère IA

Passons maintenant à la stratégie concrète : quel jeu de compétences ne sera pas remplace par l'IA, voire gagnera en valeur grâce à elle ?

1. Apprendre à maîtriser l'IA comme outil

La stratégie la plus importante, et la plus rapide à mettre en oeuvre. L'ingénieur qui voit l'IA comme un « outil » plutôt que comme une « menace » multiplié sa productivité.

• Intégrer Claude Code, Codex, Copilot et consorts dans la routine quotidienne
• Apprendre à rédiger des prompts (instructions) pertinents
• Conserver une compétence technique suffisante pour vérifier et corriger les résultats de l'IA

Pour savoir comment utiliser gratuitement les différents outils IA, jetez un oeil à « Comment utiliser l'IA gratuitement [édition 2026] ».

2. Se déplacer vers la conception et l'architecture

L'IA est forte pour « écrire du code », pas pour décider « quoi concevoir, et comment ».

• Architecture cloud : équilibrer disponibilité, scalabilité et coût
• Stratégie multi-cloud : comprendre les spécificités d'AWS, GCP et Azure pour les utiliser à bon escient
• Conception DR (reprise d'activité) : définition des RPO/RTO jusqu'aux procédures de reprise

3. Approfondir l'expertise en sécurité

La sécurité est le domaine où une erreur de l'IA a le plus gros impact. On peut donc raisonnablement estimer que la demande d'experts sécurité va augmenter avec la diffusion de l'IA.

• Conception et mise en oeuvre d'architectures zéro trust
• Compétence en réponse aux incidents de sécurité
• Conformité (ISMS, PCI DSS, RGPD, etc.)

4. Adopter la perspective SRE (Site Reliability Engineering)

La philosophie SRE popularisee par Google — « traiter l'exploitation comme un problème d'ingénierie logicielle » — gagne encore en importance à l'ère de l'IA.

• Conception et pilotage des SLI / SLO / SLA
• Décisions basées sur le budget d'erreur
• Promotion de l'automatisation (l'IA en faisant partie)
• Construction d'une culture post-mortem

5. Multiplier les contacts avec le business

Ce qui est le moins remplaçable par l'IA, c'est la capacité à faire le pont entre la technique et le business.

• Propositions d'optimisation des coûts d'infrastructure et reporting à la direction
• Définition et chiffrage des besoins infra pour de nouveaux produits
• Capacité à traduire un risque technique en risque business

7. Conclusion — pas un remplacement, une évolution

Récapitulons les conclusions de cet article.

Le message le plus important : l'ingénieur infra qui sait utiliser l'IA aura la plus grande valeur sur le marche. En déléguant les tâches routinières à l'IA, l'ingénieur peut se concentrer sur la conception, le jugement et la stratégie.

Ce n'est pas une « menace », c'est une « opportunité d'évolution ». Ne pas craindre l'IA, mais en faire son arme : voilà la stratégie de survie de l'ingénieur infra à l'ère de l'IA.

Pour une introduction à l'architecture IT globale et au développement assisté par IA, consultez aussi « Guide du développement IA pour débutants ».

FAQ