Deux gros changements ont marqué mon année : j’ai commencé une maîtrise en intelligence artificielle à l’Université Laval et, depuis septembre, je suis directeur technique chez HLC.

Aux études, je veux comprendre les modèles plus en profondeur. Au travail, je dois regarder toutes les conséquences d’une décision technique sur l’organisation. Je passe donc assez vite de la théorie aux contraintes du quotidien.

Ça ramène les projets d’IA à une question assez concrète : quelle chaîne doit rester fiable entre la donnée brute et la décision? Cette année, je me suis bâti un modèle mental en six blocs.

La chaîne complète d’un modèle

sources → préparation → entraînement → publication → décision → résultat observé
   ↑                                                                  |
   └────────────────────── monitoring et nouvelles données ──────────┘

Les sources sont les systèmes qui créent les faits : commandes, appels, capteurs ou dossiers clients. La préparation résout les identifiants, applique les fenêtres de temps et transforme les champs en features. L’entraînement ajuste les paramètres du modèle sur des exemples historiques. La publication fige une version et expose une façon contrôlée d’obtenir un score.

Le bloc décision applique un seuil, une règle ou une révision humaine. Enfin, le résultat observé indique ce qui s’est réellement passé. Sans ce retour, le système produit des scores sans apprendre si ses recommandations ont aidé.

Prenons une alerte de rupture de stock. La chaîne pourrait conserver ce dossier :

{
  "predictionId": "p-2018-10982",
  "productId": "BX-42",
  "modelVersion": "stock-risk-1.3",
  "featuresAt": "2018-12-03T06:00:00Z",
  "risk": 0.78,
  "threshold": 0.70,
  "suggestedQuantity": 24,
  "buyerDecision": 18,
  "actualDemand": 20
}

Cette trace répond à des questions que le score seul ne peut pas régler : quelle version a calculé 0,78? Quelles données étaient disponibles? La personne a-t-elle modifié la quantité? Le résultat réel était-il plus proche du modèle ou de l’ajustement? On peut ensuite calculer l’erreur et revoir les cas où le workflow a dévié.

Ce qui doit être versionné

Le fichier du modèle ne suffit pas pour reproduire une prédiction. Je veux garder ensemble :

1. le code de préparation et la définition des features;
2. la période et l’empreinte du jeu d’entraînement;
3. les paramètres appris et la librairie utilisée;
4. les métriques par segment avec le seuil choisi;
5. le contrat d’entrée et de sortie;
6. la règle qui décide quand publier, revenir en arrière ou réentraîner.

Une feature calculée différemment en production crée du training-serving skew : le modèle a appris une définition et en reçoit une autre. Par exemple, ventes_30_jours peut exclure les retours dans le notebook, mais les inclure dans l’API. Le service répond sans erreur technique tout en déplaçant les scores.

Je préférerais une seule fonction de transformation versionnée ou, au minimum, des tests qui passent le même dossier dans les deux pipelines et comparent chaque feature. Un déploiement progressif peut envoyer une petite partie des demandes au nouveau modèle et garder l’ancienne version prête pour un retour arrière.

Surveiller trois sortes de pannes

Une API disponible ne veut pas dire que le modèle fonctionne encore. Je sépare maintenant trois niveaux :

Niveau	Exemple de signal
système	erreurs, timeout, mémoire, temps de réponse
données	valeurs absentes, nouvelle catégorie, distribution déplacée
décision	précision, rappel, coût des erreurs, taux de correction humaine

La panne système se voit rapidement. La dérive des données est plus silencieuse : un nouveau code produit ou une politique commerciale déplace les entrées. La dérive du résultat prend parfois des semaines, le temps de connaître la vraie cible. Il faut donc des seuils différents, des alertes et une procédure pour désactiver le modèle sans arrêter tout le processus.

Le même raisonnement m’a suivi dans mes autres sujets de l’année. Azure expose des compteurs séparés qu’il faut rattacher à un propriétaire. Le firmware d’un drone ferme une boucle avec des capteurs et exige un test après chaque version. Une montre transforme des signaux imparfaits en métriques. RTX dépense un budget de 16,7 ms entre plusieurs passes. Dans chaque cas, la capacité visible dépend d’une chaîne mesurable en dessous.

La maîtrise me donne de meilleurs outils pour comprendre les modèles. Mon rôle de directeur technique me force à prévoir leur exploitation et la personne capable d’arrêter le système. Pour 2019, je n’ai pas une grande prédiction. J’ai une checklist plus utile : source, transformation, version, décision, résultat et reprise. Si un projet ne peut pas nommer ces six blocs, sa démo est probablement encore trop loin du quotidien.