Du prototype à la production : changer de questions.

Conserver les apprentissages

Un prototype valide une hypothèse ; son code et son architecture ne constituent pas nécessairement les fondations définitives. Identifier ce qui a été démontré, ce qui reste incertain et ce qui doit être réécrit. Décider à partir de critères explicites plutôt que du seul investissement déjà réalisé.

Rendre les environnements reproductibles

Versionner les configurations, automatiser la construction et le déploiement, séparer environnements et secrets. Les changements de schéma de données méritent autant d’attention que le code applicatif. Prévoir la compatibilité entre versions pendant une transition.

Concevoir pour l’exploitation

Définir les parcours critiques, les indicateurs de service et les alertes actionnables. Tester les sauvegardes, les erreurs de dépendances et les limites de capacité. Déterminer qui reçoit les alertes et quelles actions sont possibles.

• Centraliser les journaux utiles sans exposer les secrets.
• Prévoir des contrôles de santé représentatifs.
• Documenter restauration, rollback et accès de secours.

Livrer progressivement

Une première mise en production peut cibler un périmètre limité. Définir les critères de succès et d’arrêt avant la bascule. Collecter les observations réelles pour prioriser la suite ; une architecture plus complexe n’est justifiée que si elle répond à un besoin mesuré.