De l'ingénierie système à l'architecture cloud

J'ai commencé par exploiter des systèmes : annuaires, messagerie, sauvegardes, postes, serveurs. C'est un métier où l'on apprend vite ce qui casse, à quel moment et pourquoi.

Ce que l'exploitation apprend

• La documentation absente coûte toujours plus cher que le temps de l'écrire
• Une solution que personne ne sait exploiter n'est pas une solution
• Les incidents ne sont presque jamais techniques à la racine : ils sont organisationnels
• La complexité inutile finit toujours par se payer un dimanche soir

Le basculement

À force de réparer, j'ai voulu être présent au moment où les choix se font. L'architecture, c'est exactement ça : intervenir avant, quand une décision coûte encore un débat plutôt qu'une migration.

Ce qui change dans le cloud

Le cloud déplace la difficulté. On ne gère plus des serveurs, on gère des identités, des flux, des coûts et des dépendances. La compétence critique n'est plus l'installation, c'est le cadrage : qui accède à quoi, avec quelle garantie, à quel prix et sous quelle responsabilité.

Ce que je garde de mes années d'exploitation

Je conçois toujours en pensant à la personne qui devra exploiter le système dans trois ans, avec moins de contexte et moins de temps. Cela produit des architectures plus sobres, parfois moins impressionnantes, mais nettement plus solides.

Le conseil que je donnerais

À un ingénieur système qui veut évoluer vers l'architecture : ne jetez pas votre expérience opérationnelle, c'est votre avantage. Ajoutez-y la lecture du contexte métier, la maîtrise des coûts et la capacité à écrire une décision de manière compréhensible par un dirigeant.