Tout le monde veut coder, personne ne veut opérer
Avec le hype autour des agents de code IA, une question revient : aura-t-on encore besoin de développeurs ? Oui. Plus que jamais.
Mais pas pour les mêmes raisons qu'avant.
Écrire du code a toujours été la partie facile du job. La partie dure ? Faire tourner ce code sur la durée. Le software engineering, c'est programmer dans le temps. C'est gérer comment les systèmes évoluent.
La leçon du no-code
Prenons le no-code comme exemple de ce qu'on nous vend comme le futur — des outils custom, jetables, construits par des non-experts pour résoudre des problèmes spécifiques.
L'histoire classique :
Jean de la compta passe 10h par semaine sur une tâche répétitive. Il ne peut pas avoir de ressources dev — ils sont occupés sur le produit. Pas grave, Jean est malin. Avec un peu de Google, quelques outils no-code et des macros Excel, il se construit un outil.
Sa tâche de 10h passe à 1h. 🎉
Sauf que... le temps passe. Le business change. Les règles comptables évoluent. Jean est maintenant enchaîné à son système. Il ne peut plus partir en vacances. Personne d'autre ne peut le faire tourner. Et ça ne marche jamais vraiment bien.
C'est ce que Feynman appelait "la maladie de l'ordinateur" : automatiser des trucs c'est fun, on oublie qu'on n'en a pas toujours besoin.
Ce qui n'est PAS fun
La partie pas fun ? Faire tourner un service. De manière fiable. À l'échelle. Pendant des années.
Les gens n'achètent pas du logiciel, ils embauchent un service.
Tu te fiches de comment iCloud fonctionne — tu veux juste que tes photos apparaissent magiquement sur tous tes appareils. Tu te fiches de Word, Notion ou gDocs — tu veux juste écrire ce que tu as en tête et le partager.
Un bon logiciel est invisible.
Les vraies questions d'ingénierie
Quand le code devient facile à produire, voici les questions qui comptent :
- Quel est ton uptime ?
- Ton taux de défauts ?
- Combien de temps pour récupérer d'un incident ?
- Tu détectes les problèmes avant tes users ou après leurs plaintes ?
- Quand un fournisseur merde, tu le vois ou tu attends les tickets ?
- Tu peux scaler sans tout casser ?
- Tu peux construire un système plus gros qu'un seul cerveau ?
- À 3h du mat dans un autre fuseau horaire, quelqu'un répond ?
- Tu signeras une garantie que ton logiciel marche quand j'en ai besoin ?
Le SRE devient roi
SRE = Site Reliability Engineering.
C'est l'art de faire tourner des services de manière fiable. Monitoring, alerting, incident response, capacity planning, chaos engineering...
Avec les agents IA qui peuvent générer du code, les 90% pour avoir une démo qui marche deviennent faciles. Ce sont les 190% restants qui font la différence :
- Gestion des edge cases
- Récupération des erreurs
- Sécurité continue
- Performance à l'échelle
- Documentation vivante
- Migration sans downtime
Ce que ça veut dire pour toi
Si tu es dev : apprends l'ops. Kubernetes, observabilité, incident management. C'est là que la valeur se crée.
Si tu diriges une équipe : recrute des gens qui savent faire tourner des systèmes, pas juste coder des features.
Si tu es en train d'automatiser avec l'IA : ne sous-estime pas l'opérationnel. Le code généré, c'est 10% du travail. Le faire tourner en prod, c'est le reste.
Tu veux qu'on t'aide à mettre en prod des systèmes IA qui tiennent la route ? Parlons-en.