Il y a dix-huit mois, j’ai commencé à intégrer des assistants IA dans mon workflow quotidien. Pas pour écrire des articles de blog ou générer des images. Pour du vrai travail : architecture de systèmes, review de code, migration de bases de données, debugging de pipelines distribués.

Ce que j’ai appris depuis contredit à la fois les catastrophistes et les enthousiastes.

Ce que l’IA fait vraiment bien

Le travail de surface, à vitesse industrielle

Écrire du boilerplate, générer des tests unitaires, convertir un schéma SQL en types TypeScript, documenter une fonction existante — c’est terminé comme tâche pénible. Un bon prompt, 30 secondes, c’est fait.

// Je décris l'interface, Copilot génère la validation Zod
// Ce qui prenait 20 minutes prend maintenant 2 minutes
const ContractSchema = z.object({
  id: z.string().uuid(),
  parties: z.array(PartySchema).min(2),
  effectiveDate: z.date(),
  clauses: z.array(ClauseSchema),
  jurisdiction: z.enum(['CH', 'FR', 'DE', 'EU']),
  metadata: z.record(z.unknown()).optional(),
});

En moyenne, j’estime que 40 à 50% du temps de code pure a été absorbé par les assistants IA sur les projets 2024. Ce n’est pas anodin.

Le rubber duck à 3h du matin

Expliquer un problème complexe à Claude ou GPT-4 pour structurer sa propre pensée. C’est le meilleur rubber duck debugging jamais inventé — parce qu’il répond.

Quand un pipeline Kafka refuse de consommer des messages avec un offset commit behavior bizarre, avoir un interlocuteur qui connaît le sujet et peut hypothèse par hypothèse éliminer les causes — ça vaut cher.

La recherche de documentation

Fouiller la doc de k8s, chercher le bon flag pour une commande kubectl obscure, comprendre un comportement de Terraform state — le gain de temps est réel et mesurable.

Ce que l’IA fait mal (ou pas du tout)

L’architecture système

Décider si une feature doit être un microservice ou rester dans le monolithe. Choisir entre Kafka et NATS pour un use case donné avec les contraintes opérationnelles de l’équipe. Évaluer le risque de dette technique d’une décision de refactoring.

Les LLM donnent des réponses raisonnables à ces questions — mais ils ne connaissent pas votre contexte. Ils ne savent pas que votre équipe Ops déteste Kubernetes, que votre client a une contrainte FINMA sur la localisation des données, que ce microservice va être maintenu par un développeur junior pendant trois ans.

L’architecture, c’est 20% de technique et 80% de contraintes humaines, organisationnelles et historiques. Les LLM excellent sur les 20%.

Le debugging profond

Les bugs difficiles — les race conditions, les corruptions de données intermittentes, les memory leaks qui apparaissent après 72h d’uptime — nécessitent une compréhension intime du système, de son histoire, et du contexte opérationnel.

J’ai passé deux jours sur un bug de déduplication dans un pipeline d’ingestion de données médicales. Le problème était dans l’interaction entre le comportement de flush d’Apache NiFi, le timeout TCP du load balancer, et une logique d’idempotence incorrecte dans le consumer. Aucun LLM ne pouvait le trouver sans accès direct aux logs, à la config réseau, et à l’historique des déploiements.

La relation client

Comprendre ce qu’un client veut vraiment (pas ce qu’il dit vouloir). Gérer une conversation difficile sur un dépassement de budget. Convaincre une DSI réticente d’adopter une nouvelle approche. Sentir quand un projet déraille avant que les KPIs le montrent.

Ce sont des compétences qui se construisent sur des années d’expérience humaine. Elles ne sont pas menacées.

Le nouveau profil qui émerge

Ce que je vois sur le marché depuis 12 mois : les ingénieurs les plus demandés ne sont ni ceux qui résistent à l’IA, ni ceux qui lui délèguent tout. Ce sont ceux qui ont développé un nouveau méta-skill : savoir ce qu’on peut déléguer, ce qu’il faut superviser, et ce qui nécessite un jugement humain.

C’est une forme d’intelligence de second ordre. Pas “est-ce que je peux coder ça ?” mais “est-ce que la sortie de ce modèle est fiable pour ce use case précis ?”

Déléguer  →  génération de code, tests, docs, recherche
Superviser →  review d'architecture, sécurité, performance
Garder     →  décisions stratégiques, relation client, arbitrages complexes

Ce que ça signifie pour les équipes IT

Pour les développeurs junior : la barre d’entrée monte. Générer du code fonctionnel n’est plus une compétence différenciante. Comprendre ce qu’on génère, l’auditer, l’intégrer dans un système existant — c’est là que se fait la différence.

Pour les seniors : la valeur se déplace vers le haut. Moins de temps sur le code répétitif, plus de temps sur l’architecture, la gouvernance, la transmission. C’est une bonne nouvelle si on l’accepte.

Pour les DSI : les gains de productivité sont réels mais pas automatiques. Ils nécessitent des investissements en formation, en tooling (licences Copilot, accès API, infrastructure ML), et en gouvernance. Ce n’est pas un switch qu’on allume.

Mon bilan personnel

Je produis plus, plus vite. Les tâches répétitives ont disparu de mon quotidien. Je passe plus de temps sur les problèmes intéressants.

Mais la qualité du travail sur ces problèmes intéressants est toujours entièrement humaine. Peut-être plus que jamais — parce que c’est devenu le seul endroit où la valeur ajoutée est indiscutable.

Je ne ressens pas de menace existentielle. Je ressens une accélération.

La question n’est pas “l’IA va-t-elle remplacer les développeurs ?” La question est “quels développeurs vont apprendre à travailler avec l’IA, et lesquels ne le feront pas ?”

La réponse à cette question, elle, est assez claire.

Vous souhaitez équiper votre équipe technique pour travailler efficacement avec l’IA ? Parlons formation et accompagnement.