Mise en production d'une application : la checklist DevOps et cloud indispensable aux PME

L'application est terminée. Elle tourne sur le poste du développeur principal, la démonstration s'est bien passée, et la date de lancement approche. Reste une question que l'on se pose souvent trop tard : que se passe-t-il le jour où elle plante, le jour où il faut la mettre à jour un vendredi, ou le jour où son auteur n'est plus disponible ?

Une application est prête pour la production quand elle peut être déployée de façon reproductible, surveillée, sauvegardée et restaurée, corrigée sans interruption majeure, et exploitée par quelqu'un d'autre que son auteur. Ce sont des critères vérifiables : chacun se prouve par un test ou un document, pas par une impression.

Cet article détaille les douze points à préparer, avec pour chacun ce qu'une PME doit mettre en place, l'erreur à éviter et le critère qui permet de le considérer comme prêt. Il se termine par une checklist de préproduction réutilisable.

Développement ou production : ce qui change vraiment

En développement, une erreur coûte quelques minutes. En production, elle touche des clients, des données réelles et parfois le chiffre d'affaires. La mise en production consiste à rendre l'application robuste à ce changement d'échelle des conséquences.

Les 12 points à préparer avant la mise en production

L'ordre suit la logique d'un projet, de l'organisation des environnements à la passation. Chaque point indique ce qu'il faut préparer, l'erreur à éviter et un critère de validation. Aucune technologie citée n'est indispensable : ce sont des exemples, à choisir selon le contexte.

1. La séparation des environnements

Un environnement est un ensemble complet (application, base de données, configuration, accès) dans lequel une version tourne. Une PME a généralement besoin d'au moins trois environnements : développement, test ou préproduction, production.

• À préparer : des environnements distincts, avec des bases de données, des identifiants et, sur AWS, idéalement des comptes séparés pour la production. La préproduction doit ressembler le plus possible à la production.
• Erreur à éviter : copier les données personnelles de production dans l'environnement de test sans les pseudonymiser, ou partager un même mot de passe de base entre les environnements.
• Prêt quand : une action menée en test ne peut matériellement pas modifier la production.

2. L'infrastructure cloud et le choix de l'architecture

• À préparer : une architecture dimensionnée pour les besoins réels : où s'exécute l'application (machine virtuelle, conteneurs, fonctions serverless), où sont stockées les données, dans quelle région, avec quel niveau de disponibilité. Les services gérés (base de données, équilibreur de charge, stockage objet) réduisent l'exploitation à votre charge, au prix d'une dépendance plus forte au fournisseur.
• Erreur à éviter : choisir une plateforme parce qu'elle est à la mode. Un orchestrateur comme Kubernetes peut être surdimensionné pour une application unique ; une seule machine sans sauvegarde est sous-dimensionnée pour une application critique. Aucun fournisseur ni aucune technologie ne convient à toutes les entreprises.
• Prêt quand : l'architecture est décrite dans un schéma, et ses points de défaillance uniques sont connus et assumés. Si le choix du fournisseur lui-même est ouvert, notre article sur la migration d'AWS vers un cloud européen détaille les critères de comparaison.

3. Les tests automatisés et la validation avant déploiement

• À préparer : des tests unitaires sur la logique métier, des tests d'intégration sur les accès à la base et aux services externes, et quelques tests de bout en bout sur les parcours critiques (inscription, paiement, commande). Les migrations de schéma de base de données doivent être testées sur une copie représentative.
• Erreur à éviter : des tests qui existent mais ne sont exécutés que sur le poste du développeur, ou des tests instables que l'équipe a pris l'habitude d'ignorer.
• Prêt quand : un changement qui casse un parcours critique est bloqué automatiquement avant d'atteindre la production.

4. Le pipeline CI/CD

L'intégration continue (CI) compile et teste automatiquement chaque modification. Le déploiement continu (CD) livre automatiquement la version validée vers un environnement. Ensemble, ils forment le pipeline.

• À préparer : un pipeline dans un outil comme GitHub Actions, GitLab CI ou AWS CodePipeline, qui construit un artefact une seule fois (image de conteneur, archive) puis déploie ce même artefact en test puis en production. Une validation humaine peut être exigée avant la production. Le pipeline doit accéder au cloud avec des identifiants temporaires : GitHub Actions, par exemple, peut obtenir des accès AWS par OpenID Connect sans stocker de clé de longue durée.
• Erreur à éviter : reconstruire l'application différemment pour chaque environnement, ou stocker une clé d'accès administrateur dans les paramètres du pipeline.
• Prêt quand : un autre membre de l'équipe peut déployer sans l'auteur de l'application, et chaque déploiement est tracé (qui, quelle version, quand).

5. Les secrets et les variables d'environnement

• À préparer : séparer strictement la configuration du code. La méthodologie Twelve-Factor App propose un test simple : le code pourrait-il être rendu public à tout instant sans compromettre un seul identifiant ? Les secrets (mots de passe, jetons, clés privées) se stockent dans un gestionnaire de secrets et sont injectés à l'exécution.
• Erreur à éviter : un fichier .env versionné, un secret intégré à une image de conteneur, ou un jeton qui apparaît en clair dans les journaux.
• Prêt quand : l'historique du dépôt a été analysé sans trouver de secret actif, et chaque secret a un propriétaire et une procédure de renouvellement.

6. L'Infrastructure as Code et la reproductibilité

L'Infrastructure as Code décrit l'infrastructure dans des fichiers versionnés (Terraform, AWS CDK, CloudFormation, Pulumi) plutôt que par des clics dans une console.

• À préparer : le code de l'infrastructure dans le dépôt, relu comme le code applicatif, et appliqué par le pipeline. Avec Terraform, l'état de l'infrastructure (state) doit être stocké à distance, verrouillé et protégé : HashiCorp rappelle qu'il peut contenir des données sensibles, comme des mots de passe initiaux de bases de données.
• Erreur à éviter : modifier la production à la main « juste cette fois » : le code ne décrit plus la réalité, et la prochaine application peut annuler la correction.
• Prêt quand : un environnement complet peut être recréé à partir du code et d'une procédure écrite.

7. HTTPS, gestion des accès et sécurité applicative

• À préparer : HTTPS partout, avec redirection du HTTP et renouvellement automatique des certificats (sur AWS, AWS Certificate Manager le permet pour les équilibreurs de charge et CloudFront) ; accès d'administration limités et protégés par authentification multifacteur ; dépendances logicielles analysées. L'OWASP Top 10:2025 sert de référence pour les risques applicatifs : il place en tête le contrôle d'accès défaillant, puis la mauvaise configuration et les défaillances de la chaîne d'approvisionnement logicielle.
• Erreur à éviter : une console d'administration accessible depuis Internet avec un compte partagé, ou des dépendances jamais mises à jour depuis le début du projet.
• Prêt quand : les parcours sensibles ont été revus au regard de ces risques, et la configuration du compte cloud a été vérifiée (voir les 12 points d'un audit de sécurité AWS).

8. Les logs, le monitoring, les alertes et l'observabilité

L'observabilité est la capacité à comprendre ce qui se passe dans un système à partir de ce qu'il émet : journaux, métriques et traces.

• À préparer : des journaux structurés et centralisés, sans secret ni donnée personnelle inutile, avec une durée de conservation définie ; un contrôle de disponibilité externe ; des tableaux de bord et des alertes. Le livre de Google sur l'ingénierie de fiabilité recommande de suivre en priorité quatre signaux : latence, trafic, erreurs et saturation.
• Erreur à éviter : des dizaines d'alertes que personne ne lit, ou des alertes sur l'utilisation du processeur alors que les utilisateurs subissent des erreurs.
• Prêt quand : l'équipe apprend une panne avant ses clients, et chaque alerte a un destinataire qui sait quoi faire.

9. Les sauvegardes et les tests de restauration

• À préparer : des sauvegardes automatiques de la base de données (sur les services gérés, la restauration à un instant donné est souvent disponible), du stockage de fichiers, et de la configuration nécessaire pour reconstruire. Pour chaque application, deux objectifs : la perte de données acceptable (RPO) et la durée d'interruption acceptable (RTO).
• Erreur à éviter : constater que la sauvegarde existe sans jamais l'avoir restaurée, ou découvrir le jour de l'incident qu'elle ne contient pas les fichiers déposés par les utilisateurs.
• Prêt quand : une restauration complète a été réalisée dans un environnement séparé, chronométrée et documentée.

10. La stratégie de rollback et la gestion des incidents

Le rollback est le retour à la version précédente après un déploiement qui pose problème.

• À préparer : une stratégie de déploiement adaptée (remplacement progressif des instances, déploiement bleu-vert, déploiement canari) et un mécanisme de retour. Sur Amazon ECS, par exemple, le déploiement progressif peut s'accompagner d'un disjoncteur qui annule automatiquement un déploiement en échec. Les migrations de base de données doivent rester compatibles avec la version précédente du code, car revenir en arrière sur le code ne revient pas en arrière sur le schéma.
• Erreur à éviter : découvrir pendant un incident que le retour arrière est impossible parce qu'une colonne a été supprimée. Notre guide de migration rappelle aussi que le retour arrière n'est pas un simple changement de DNS dès que des données ont été écrites.
• Prêt quand : un rollback a été exécuté volontairement au moins une fois, et une procédure d'incident désigne qui décide et qui communique.

11. Les performances, la disponibilité et les coûts

• À préparer : un test de charge en préproduction sur le trafic attendu et ses pics ; des délais d'expiration et des limites sur les appels externes ; des bornes à la mise à l'échelle automatique ; un objectif de disponibilité réaliste ; un budget et des alertes de coûts.
• Erreur à éviter : une mise à l'échelle automatique sans plafond, qui transforme un pic de trafic ou une attaque en facture inattendue.
• Prêt quand : les limites de l'application sont connues et chiffrées, et une alerte prévient d'une dérive des coûts. Pour la suite, notre méthode pour réduire une facture AWS sans risque pour la production détaille les leviers.

12. La documentation, le transfert de compétences et les responsabilités

• À préparer : un schéma d'architecture à jour ; des procédures pour déployer, revenir en arrière, restaurer et renouveler un secret ; la liste des accès et de leurs propriétaires ; un responsable nommé pour l'exploitation et un circuit d'astreinte adapté à la taille de l'équipe.
• Erreur à éviter : une connaissance qui n'existe que dans la tête d'une personne ou d'un prestataire.
• Prêt quand : quelqu'un d'autre que l'auteur a déployé et restauré l'application en suivant uniquement la documentation.

Checklist de préproduction

• Les environnements de développement, test et production sont séparés, avec des identifiants distincts.
• La préproduction est proche de la production, sans données personnelles réelles non protégées.
• L'architecture est décrite dans un schéma, avec ses points de défaillance connus.
• Les tests automatisés couvrent les parcours critiques et s'exécutent dans le pipeline.
• Le même artefact est déployé en test puis en production.
• Le pipeline accède au cloud avec des identifiants temporaires.
• Aucun secret n'est présent dans le code, les images ou les journaux.
• L'infrastructure est décrite dans du code versionné, et son état est protégé.
• HTTPS est actif partout, avec renouvellement automatique des certificats.
• Les accès d'administration sont limités et protégés par MFA.
• Les journaux sont centralisés, avec une durée de conservation définie.
• Latence, trafic, erreurs et saturation sont suivis, et les alertes ont un destinataire.
• Une restauration complète a été testée et chronométrée.
• Un rollback a été exécuté au moins une fois.
• Un test de charge a été réalisé sur le trafic attendu.
• Un budget et des alertes de coûts sont en place.
• Les procédures de déploiement, de retour arrière et de restauration sont écrites.
• Un responsable de l'exploitation est nommé.

Ce que doit livrer une mission de mise en production

Une mission de mise en production se juge à ce que l'équipe peut faire seule après le départ du prestataire : déployer, surveiller, restaurer et revenir en arrière.

CERVOX Services intervient sur AWS par missions cadrées qui correspondent à ces livrables. La mise en ligne d'une application AWS déploie votre application sur votre propre compte, avec son domaine, les services nécessaires et la sauvegarde de ses données, puis la documentation et la transmission. Les mises en production automatisées installent dans votre dépôt un pipeline avec les contrôles prévus ; le retour arrière est exécuté une fois avec vous, et la mission se termine quand un membre de votre équipe a relancé le pipeline. Les missions alertes et sauvegardes et infrastructure AWS reprise en code complètent ce socle selon votre situation.

Questions fréquentes

Qu'est-ce qu'une application prête pour la production ?

C'est une application qui peut être déployée de façon reproductible, surveillée, sauvegardée et restaurée, corrigée ou ramenée à sa version précédente sans interruption majeure, et exploitée par quelqu'un d'autre que son auteur, avec une documentation à jour.

Quelle différence entre intégration continue et déploiement continu ?

L'intégration continue compile et teste automatiquement chaque modification du code. Le déploiement continu livre automatiquement une version validée vers un environnement. Une PME peut adopter l'intégration continue sans déployer automatiquement en production, en gardant une validation humaine.

Faut-il un environnement de préproduction ?

Pour une application qui a des utilisateurs réels, c'est fortement recommandé. La préproduction permet de tester les déploiements, les migrations de base de données et les retours arrière dans des conditions proches de la production, sans risque pour les clients.

Faut-il utiliser Kubernetes pour mettre une application en production ?

Non, pas nécessairement. Kubernetes répond à des besoins d'orchestration de nombreux services. Pour une application unique ou quelques services, un service de conteneurs géré, une plateforme d'application ou des fonctions serverless peuvent suffire avec moins d'exploitation. Le choix dépend de l'application, de l'équipe et des contraintes.

Combien de temps faut-il pour préparer une mise en production ?

Cela dépend de l'état de départ : une application déjà testée, conteneurisée et configurée par variables d'environnement demande beaucoup moins de travail qu'une application installée à la main. Un inventaire de ces douze points permet d'estimer l'effort de façon réaliste.

Conclusion : prouver chaque point avant le lancement

Mettre une application en production, ce n'est pas seulement la rendre accessible. C'est pouvoir la déployer, la surveiller, la restaurer, la corriger et la confier à quelqu'un d'autre. Chacun des douze points se valide par une preuve concrète : un déploiement tracé, une restauration chronométrée, un rollback exécuté, une procédure suivie par une autre personne.

Si votre application est prête mais pas encore en production, ou si vos mises en production restent manuelles et dépendent d'une seule personne, décrivez votre situation en quelques lignes : nous vous disons si nous pouvons intervenir, et comment. Une estimation écrite vous est remise sous 24 h ouvrées après un premier échange de 20 minutes.