2012 se termine dans un entre-deux pour moi. Mon passage chez NOVIPRO à Paris a pris fin en septembre et je ne sais pas encore exactement à quoi ressemblera la prochaine étape. Techniquement, l’année a surtout montré des systèmes qui commencent avant que l’organisation ait fini de les nommer.

Un service SaaS entre avec un essai. Une application mobile stocke des données hors du réseau. Un cluster Hadoop absorbe des logs avant que leur définition soit stable. Dans les trois cas, le premier geste est rapide; le cycle complet reste à construire.

Comparer les trajets plutôt que les étiquettes

Pour un outil SaaS :

annuaire → compte du fournisseur → tenant → données → export

Pour une inspection mobile :

capteur → stockage local → file → API → transaction

Pour une analyse distribuée :

sources → fichiers bruts → tâches map → shuffle → reduce → résultat

Ces flux ont des mécanismes différents, mais quatre contrôles communs :

1. un identifiant stable qui suit l’objet;
2. un responsable pour sa définition et ses accès;
3. une preuve que le traitement est terminé;
4. une façon testée de récupérer ou d’exporter.

Le SaaS sans export enferme le projet. Le mobile sans reçu confond « sauvé ici » et « reçu là-bas ». Le calcul distribué sans compte de rejets peut réussir avec des données manquantes. Le contrôle utile se place donc au point où l’état change.

La vitesse amplifie aussi les erreurs

Une reprise automatique sans idempotence crée des doublons. Un tenant mal filtré expose un client à un autre. Un log trop détaillé devient une base de surveillance. Un modèle apprend les biais de ses données. Ce ne sont pas des arguments pour ralentir tout le monde; ce sont des raisons d’inclure les limites dans le chemin rapide.

Je dessinerais pour chaque service une petite machine à états. Un fichier mobile passe de local à en attente, reçu ou rejeté. Un jeu de données passe de brut à validé, publié ou quarantaine. Un abonnement passe de essai à approuvé, revu ou fermé. L’état visible permet au support et à l’utilisateur de reprendre sans deviner.

Les coûts suivent aussi l’usage. Une VM oubliée, un stockage sans rétention et une API appelée en boucle continuent de facturer. Les étiquettes, budgets et alertes doivent naître avec la ressource. Couper automatiquement une production n’est pas toujours prudent; arrêter un laboratoire expiré l’est beaucoup plus.

Faire vivre les états dans un tableau d’exploitation

Une machine à états utile doit produire des compteurs. Je voudrais connaître le nombre d’objets dans chaque état, leur âge et la dernière transition. Dix éléments en attente depuis une minute sont normaux; un seul depuis deux jours mérite une enquête. Chaque transition enregistre l’acteur, la version et la cause. Une opération de réparation ne modifie pas arbitrairement la colonne : elle appelle la même règle que le flux normal et laisse un audit. Ce tableau commun permet aux équipes métier et techniques de parler du même travail sans ouvrir la base et deviner ce que signifie une valeur.

Pour la prochaine année, j’appliquerais un test de six questions à tout nouveau service : quelles composantes, quel état, quelle identité, quelle panne, quelle reprise et quelle sortie? Si l’équipe répond avant le pilote, elle garde la vitesse tout en évitant que le prototype devienne une dépendance incomprise.