Préparer une mise en production Dataiku sans casser la prod

Le passage en production d'un projet Dataiku paraît simple : on crée un bundle, on l'importe sur l'instance d'automation, on active. En pratique, les échecs se concentrent sur quelques points précis, et ce sont presque toujours les mêmes.

Le point commun de ces échecs : ils ne viennent pas du code. Ils viennent de l'écart de configuration entre les instances.

Ce qu'un bundle emporte, et ce qu'il laisse

C'est la première source de surprise. Un bundle contient la définition du projet : structure du flow, recipes, scénarios, métadonnées, et les données que vous choisissez d'inclure explicitement.

Il n'emporte pas :

• Les connexions, qui existent au niveau de l'instance.
• Les environnements de code, qui doivent exister côté cible.
• Les plugins et leurs versions.
• Les variables d'instance et les secrets.
• Le contenu des datasets non inclus explicitement.

Un projet qui fonctionne parfaitement en design peut échouer au premier run en automation simplement parce qu'une connexion n'y porte pas le même nom.

Les quatre écarts qui font échouer un déploiement

1. Les connexions portent des noms différents

De loin la cause la plus fréquente. Le projet référence une connexion par son nom. Si l'instance cible l'a nommée autrement, le bundle s'importe sans broncher, puis tout casse à la première exécution.

La parade est une convention de nommage identique sur toutes les instances : même nom partout, seuls les paramètres derrière changent. C'est évident, et c'est rarement fait.

2. L'environnement de code n'existe pas côté cible

Un projet qui utilise un environnement Python personnalisé le référence par son nom. S'il n'a pas été créé sur l'instance d'automation, avec les mêmes paquets, les recipes en code échouent.

À traiter comme une dépendance de déploiement à part entière : l'environnement se prépare avant le premier bundle, pas au moment où le déploiement échoue.

3. Les variables sont écrasées

Un bundle embarque les variables du projet telles qu'elles étaient à sa création. Si l'instance cible avait des valeurs spécifiques (chemins, paramètres d'environnement), l'import peut les remplacer par celles de design, sans que rien ne le signale.

D'où la règle : tout ce qui change entre design et production passe par des variables d'instance, jamais par des variables de projet.

4. Les déclencheurs sont activés trop tôt

Un déploiement réussi et un scénario qui tourne correctement sont deux choses différentes. Activer les déclencheurs juste après l'import, c'est choisir de découvrir les problèmes en production, souvent à trois heures du matin.

La séquence que j'applique

L'étape 4 est celle qu'on saute quand on est pressé, et c'est exactement celle qui révèle les problèmes de configuration. Quelques minutes de run manuel valent mieux qu'un incident nocturne.

La question à se poser avant d'activer

Il y en a une seule, et elle est simple : si ça se passe mal dans dix minutes, comment je reviens à l'état précédent ?

Si la réponse n'est pas immédiate, le déploiement n'est pas prêt. Garder la version précédente importée mais inactive est la solution la plus simple, et elle coûte zéro.

Le cas particulier des périodes à traiter

Sur un traitement qui reconstruit un historique, la période du premier lancement n'est presque jamais celle du fonctionnement courant. Se tromper produit soit des trous, soit des doublons.

Les doublons sont les pires : ils ne se remarquent que plus tard, quand ils ont déjà été consommés par les chaînes en aval.