Ma première année complète comme architecte de solutions chez HLC se termine. Je porte davantage attention à ce qui déploie, relie et garde les systèmes en marche. Les microservices, conteneurs et pipelines rendent impossible de laisser l’exploitation dans une note au bas du diagramme.

Un service possède code, artefact, configuration, identité, données, métriques et reprise. Si l’équipe n’en possède qu’un morceau, l’autonomie promise est théorique. L’architecture doit montrer comment ces éléments traversent les environnements.

Du commit à une opération récupérable

Le trajet que je veux voir est :

1. commit revu et identifié;
2. build reproductible;
3. artefact immuable et analysé;
4. tests de contrat et d’intégration;
5. déploiement graduel;
6. sonde fonctionnelle et métriques comparées;
7. décision d’avancer ou revenir;
8. runbook si la donnée doit être compensée.

Pour un conteneur, tuer l’instance ne doit pas perdre l’état. Pour un microservice, renvoyer un événement ne doit pas doubler la commande. Pour AX, remettre un ancien binaire ne doit pas faire croire qu’une facture envoyée a disparu. Ces contraintes influencent le code avant la livraison.

La corrélation relie navigateur, API, file et ERP. Les métriques suivent latence, erreurs, âge des messages et débit. Une alerte nomme un symptôme avec propriétaire. Sans ce retour, le pipeline ne sait pas si sa version fonctionne réellement.

Les choix d’organisation apparaissent dans les frontières

Les microservices exigent une équipe capable d’opérer chaque service. Sinon, cent services attendent la même équipe centrale pour le déploiement et la base. Les conteneurs simplifient le paquet, pas le réseau, les secrets ou le stockage. DevOps demande une boucle commune, pas un nouveau serveur de build.

Je comparerais toute nouvelle séparation à un monolithe modulaire : besoin d’échelle indépendante, cadence, propriété de donnée et coût de panne. Si les avantages ne sont pas concrets, une transaction locale et un processus unique restent précieux.

La sécurité entre dans le pipeline : dépendances, comptes de service, secrets, rôles et journaux. Les privilèges de déploiement sont séparés des comptes quotidiens. Une compromission du pipeline a accès à toutes les productions; ses artefacts et actions doivent être traçables.

Faire un inventaire des capacités de production

Pour chaque service, je remplirais une grille : dépôt, artefact, environnement, données, secret, tableau, alerte, sauvegarde, runbook et équipe. Une case vide n’interdit pas automatiquement la mise en ligne; elle révèle le risque accepté et sa date. Les services critiques doivent atteindre un niveau minimal avant de recevoir des clients. La grille est vérifiée par un petit appel réel, pas seulement une URL déclarée. Lorsqu’une équipe change, la propriété est transférée avec accès et connaissances. Ce mécanisme évite qu’un diagramme de microservices cache dix applications sans personne capable de restaurer leur état ou tourner leur certificat.

Pour 2016, je demanderais une démonstration de panne dans chaque revue : instance tuée, message doublé, identité absente ou migration interrompue. L’exploitation n’est pas la dernière phase. Elle est la preuve que le système conserve son état et son sens lorsque le prochain composant fait exactement ce qu’on craignait.