- Même à l’ère du coding agentique, la demande en software engineers devrait au contraire augmenter, et l’enjeu central n’est pas l’écriture de code mais la capacité à exploiter des services
- Écrire du code a toujours été la partie facile ; le vrai défi consiste à faire tourner un système de manière fiable sur le long terme
- Comme l’ont montré le no-code et les feuilles de calcul, même des non-spécialistes peuvent créer des outils, mais la charge de maintenance et d’exploitation finit par exiger une ingénierie professionnelle
- Les utilisateurs n’achètent pas un logiciel mais un service ; un bon logiciel doit fonctionner de façon invisible
- Uptime, taux d’incident, vitesse de restauration, mises à jour de sécurité : l’excellence opérationnelle (operational excellence) est au cœur de la compétitivité future
- Pour répondre à toutes ces exigences, le SRE est en train de devenir le centre de gravité du software engineering
Le SRE devrait devenir le poste le plus recruté
- Quand le code devient moins cher, c’est l’excellence opérationnelle qui gagne
- Tout le monde peut créer une démo greenfield, mais pour faire tourner un service de façon fiable, il faut de vraies compétences d’ingénierie
- « Tout le monde veut écrire des démos greenfield, mais personne ne veut exploiter des services »
- Le software engineering n’est pas simplement du programming, c’est la gestion de systèmes qui évoluent dans le temps
La leçon de l’ère du no-code et des feuilles de calcul
- Joe, comptable, a réduit de 10 heures à 1 heure un travail répétitif hebdomadaire grâce à des outils no-code et des macros de feuille de calcul
- Au départ, les résultats étaient nets, mais avec le temps la complexité a rapidement augmenté
- Changements de l’environnement métier, évolution des règles comptables, accumulation de problèmes de fuseaux horaires et d’heure d’été
- Chaque semaine révélait de nouveaux edge cases, nécessitant des retouches et corrections continues
- Au final, Joe s’est retrouvé prisonnier du système qu’il avait lui-même créé
- Même en vacances, il devait garder le système à l’esprit, et il était difficile d’en confier l’exploitation à quelqu’un d’autre
- Le simple fait d’exécuter le code et de vérifier les résultats devenait une source d’anxiété et de tension
La maladie de l’ordinateur (The Computer Disease)
- Concept nommé par Feynman : le problème avec les ordinateurs, c’est qu’ils incitent à les tripoter sans cesse
- L’automatisation est amusante en soi, mais il existe un piège : automatiser des domaines qui n’en ont pas besoin et accroître la complexité
- La vraie charge se situe dans l’exploitation du service
- Le maintenir en fonctionnement de manière fiable
- Le faire passer à l’échelle sans incident dans des environnements de grande ampleur
- Le gérer de façon continue pendant des années
- Fournir un service repose avant tout sur la stabilité, la fiabilité et la continuité
Pourquoi l’excellence opérationnelle est l’avenir
- Les gens n’achètent pas un logiciel : ils mandatent un service qui résout leur problème
- Personne ne s’intéresse au fonctionnement interne d’iCloud ; on s’attend simplement à ce que les photos se synchronisent toujours automatiquement entre les appareils
- Peu importe comment Word, Notion ou gDocs sont construits ; l’essentiel est l’expérience d’écrire et de partager ses idées
- Plus que l’architecture du réseau de paiement, ce qui compte, c’est que le latte matcha à 7 dollars soit payé sans problème
- Un bon logiciel est invisible : il fonctionne naturellement, sans se faire remarquer
Les vrais défis d’ingénierie
- Les 90 % du début pour produire une démo fonctionnelle sont faciles ; les 190 % restants sont ceux qui comptent vraiment
- Les questions auxquelles il faut répondre du point de vue opérationnel :
- Quel est le niveau d’uptime ?
- Quel est le taux d’incidents ?
- En cas de panne, combien de temps faut-il pour rétablir le service ?
- Détecte-t-on les problèmes avant que les utilisateurs ne s’en aperçoivent ?
- Peut-on gérer les dépendances upstream ?
- En cas de problème chez un vendor, le détecte-t-on avant les plaintes des utilisateurs ?
- Combien de temps faut-il pour intégrer une idée proposée par un utilisateur ?
- Empêche-t-on les ingénieurs de casser mutuellement leurs systèmes ?
- Existe-t-il un système permettant aux ingénieurs de continuer à avancer sans que l’application ne devienne un amas confus ?
- Peut-on gérer un logiciel d’une taille qui dépasse ce qu’une seule personne peut contenir dans sa tête ?
- Si un incident majeur survient dans un fuseau horaire avec 12 heures de décalage pendant que les ingénieurs dorment, est-il corrigé avant que les utilisateurs n’abandonnent ?
- Peut-on récupérer d’une panne interne comme d’une panne upstream, et des données critiques sont-elles perdues ?
- Applique-t-on régulièrement les mises à jour de sécurité ?
- Les données des utilisateurs sont-elles exfiltrées ?
- Est-ce fiable ?
- Peut-on compter dessus ?
- Existe-t-il des éléments concrets pour fonder cette confiance ?
- Peut-on signer une garantie juridiquement contraignante affirmant que le logiciel fonctionnera quand il le faudra ?
- Voilà les vrais défis d’ingénierie, et écrire du code n’en est que la partie facile
Aucun commentaire pour le moment.