Je pensais faire un palmarès des technologies qui ont « changé la game » en 2019. En relisant mes articles, je vois surtout une année où j’ai regardé ce qui arrive après le premier wow.

Un modèle peut être impressionnant pendant l’entraînement. Après ça, les données changent, il faut mesurer les erreurs et quelqu’un devra peut-être le retirer. Une stack data rend la logique plus visible, mais elle ajoute aussi des connecteurs, des fournisseurs et des coûts.

Le cloud est maintenant une option mature, mais ça ne justifie pas chaque migration. Le zero trust donne une direction intéressante, mais aucune licence ne va retirer les anciens accès à notre place.

Comme directeur technique, je passe plus de temps sur cette partie moins visible. Une procédure de retrait ou un test de reprise n’attire pas une foule. C’est quand même ce qui permet de garder une technologie en marche après la présentation.

Ma fiche de passage vers la production

Je résume maintenant un nouveau service sur une page avant d’augmenter son usage :

service: stock-recommendation
decision: quantity-to-order
owner: supply-platform
users: 24 buyers
slo:
  availability: 99.9%
  latency_p95: 500ms
  data_freshness: 6h
dependencies:
  - erp-orders
  - supplier-lead-times
fallback: manual-reorder-rule-v2
alerts:
  - api-oncall
  - data-quality-oncall
cost_unit: dollars_per_1000_recommendations
recovery: runbook-42
review_date: 2020-03-31
retirement: model-registry-procedure

Le propriétaire prend les décisions sur le service; ce n’est pas seulement la personne qui a écrit le premier notebook. Le SLO décrit la qualité que les utilisateurs peuvent attendre. Les dépendances montrent ce qui peut le rendre faux ou indisponible. Le fallback garde le processus en marche. Les alertes indiquent qui doit agir, et la date de revue empêche la première approbation de devenir permanente.

Trois voyants au lieu d’un seul

Pour un système d’IA, je sépare la santé en trois niveaux :

Niveau	Question	Exemple de mesure
service	répond-il correctement?	erreurs, p95, saturation
données	les entrées ont-elles encore le bon sens?	fraîcheur, valeurs manquantes, dérive
décision	aide-t-il encore?	coût des erreurs, corrections humaines, résultat réel

Un endpoint peut afficher 99,99 % de disponibilité pendant que la source ERP n’a pas chargé depuis deux jours. Le service est techniquement vert et fonctionnellement faux. L’alerte de fraîcheur doit alors couper la recommandation ou afficher clairement sa date, pas laisser un vieux score circuler comme s’il venait d’être calculé.

Le SLO produit aussi un budget d’erreur. À 99,9 % sur 30 jours, on accepte environ 43 minutes d’indisponibilité. Si les déploiements ont déjà consommé cette marge, l’équipe ralentit les changements et travaille sur la fiabilité. Le nombre exact dépend du besoin; le mécanisme rend le compromis visible.

Tester la reprise comme une fonction

Un runbook utile commence par un signal et finit par une vérification :

alerte: taux d’erreur > 5 % pendant 5 minutes
  1. identifier la version et la dépendance en erreur
  2. arrêter la promotion en cours
  3. basculer vers la version précédente ou le fallback
  4. vérifier un dossier connu de bout en bout
  5. informer les opérations de la période touchée
  6. conserver les traces pour rejouer ou corriger

Je veux exécuter cette séquence avant la panne. Un fallback jamais testé peut être plus lent, avoir perdu ses accès ou dépendre de la même base en problème. L’exercice mesure le temps réel de reprise et révèle les étapes qui n’existent que dans la tête d’une personne.

La pile data moderne rend le lineage essentiel pour cet incident. Si une source est fausse, il faut trouver les modèles, tableaux et décisions qui l’ont consommée, corriger la période, puis les rejouer dans l’ordre. Un diagramme statique ne suffit pas; le pipeline doit enregistrer les lots et versions réellement utilisés.

Le coût et la sortie font partie du design

Le cloud et les services gérés déplacent la facture vers l’usage. Je suivrais une unité liée au travail : coût par mille recommandations, par commande ou par téraoctet transformé. Une hausse peut venir d’une requête qui relit tout l’historique, d’un retry sans limite ou d’une ressource oubliée.

Le retrait est l’autre bout du cycle. Le registre doit montrer les consommateurs, la règle de remplacement et les données à conserver pour expliquer les anciennes décisions. Quand le service n’apporte plus assez de valeur, on coupe progressivement les appels, surveille qu’ils tombent à zéro, archive le minimum nécessaire et supprime l’infrastructure.

Quelques événements ont rendu ces idées concrètes cette année. Les règles canadiennes demandent de planifier le drone comme un aéronef. Les deepfakes font de la provenance une composante de la preuve. Stadia expose chaque milliseconde entre la commande et le pixel. Dans chaque cas, le système complet compte plus que la capacité montrée dans la démo.

La maîtrise en IA enlève elle aussi quelques réponses faciles. Plus je comprends les modèles, moins le mot intelligence explique ce qu’ils font. En 2020, je vais continuer de demander la fiche : propriétaire, SLO, données, alerte, reprise, coût et retrait. Si le projet tient encore après qu’on a rempli ces cases et testé le fallback, je suis pas mal plus prêt à l’essayer.