Feature freeze et code freeze dans le développement d'applications : essence, différences et rôle

Qu'est-ce qu'un feature freeze ?

Feature freeze est une interdiction temporaire d'ajouter de nouvelles fonctionnalités à la base de code, introduite avant une mise en production planifiée. L'équipe cesse de fusionner les fonctionnalités et se consacre à la correction de bugs, à l'optimisation et au polissage du code existant. Les développeurs finalisent les fonctionnalités incomplètes uniquement dans le cadre des corrections de bugs, sans élargir le périmètre.

Le feature freeze résout le problème des fonctionnalités en cours (work-in-progress) qui n'arrivent pas à temps pour la mise en production mais sont déjà partiellement fusionnées dans la branche principale. Si de nouvelles fonctionnalités continuent d'être fusionnées, le risque de régression augmente : chaque nouvelle intégration nécessite de retester les modules déjà terminés. Feature freeze fixe le périmètre de la mise en production, le transformant d'une cible mouvante en un ensemble stable de fonctionnalités.

Une clarification importante : feature freeze ≠ code freeze. Pendant un feature freeze, les corrections de bugs, le refactoring, les mises à jour de dépendances et la documentation sont autorisés. Seules les nouvelles fonctionnalités visibles par l'utilisateur sont interdites, c'est-à-dire tout code qui modifie le comportement de l'application du point de vue de l'utilisateur. Vérification en code review : si un PR ajoute un nouvel écran, bouton ou méthode d'API, il est rejeté jusqu'à la levée du gel.

Qu'est-ce qu'un code freeze et en quoi diffère-t-il du feature freeze

Code freeze est une pratique plus stricte dans laquelle toutes les modifications du code sont complètement interdites. Même les corrections de bugs ne sont pas autorisées à moins qu'elles ne soient critiques. Le code freeze est introduit pour une courte période (généralement 24 à 48 heures) et garantit que le build de mise en production est assemblé à partir d'un ensemble fixe de commits.

La différence entre le feature freeze et le code freeze réside dans le niveau de contrôle. Le feature freeze gère le périmètre : ce qui sera exactement inclus dans la mise en production. Le code freeze gère la qualité : il élimine le risque d'introduire un nouveau bug la veille de la mise en production. En pratique, de nombreuses équipes utilisent un modèle en deux étapes : 1 à 2 semaines avant la mise en production, un feature freeze ; 24 à 48 heures avant, un code freeze. Code freeze est particulièrement pertinent pour les applications mobiles, où le build doit être téléchargé sur le store plusieurs jours avant la date de mise en production planifiée.

L'exception au code freeze concerne les corrections de sécurité pour les vulnérabilités critiques (CVE avec un score de 9+). Ces modifications passent par un processus d'urgence avec une revue de code accélérée obligatoire et une notification à l'équipe. Toutes les autres modifications sont reportées au prochain cycle de mise en production.

Feature freeze vs code freeze : comparaison

Le choix entre feature freeze et code freeze dépend de la maturité de l'équipe et de la fréquence des mises en production. Les équipes avec CI/CD et feature flags peuvent n'avoir besoin que d'un code freeze de 24 heures, tandis que les équipes avec des mises en production mensuelles utilisent plus souvent les deux gels séquentiellement.

Types de gels : total, partiel et BAU-freeze

En plus du feature freeze total et du code freeze, il existe des options plus flexibles. Partial feature freeze (gel partiel) bloque les nouvelles fonctionnalités uniquement dans certains modules, par exemple dans le module de paiement ou le module d'autorisation, laissant les autres composants ouverts aux modifications.

Le BAU-freeze (business as usual freeze) est une option de compromis où seules les grandes fonctionnalités dont le volume de modifications dépasse un certain seuil (par exemple, 500 lignes de code) sont interdites. Les améliorations mineures, les ajustements d'UI et les corrections de bugs continuent d'être fusionnés. BAU-freeze est pratique pour les projets en livraison continue, où un arrêt complet du développement pendant une semaine n'est pas économiquement viable.

Il existe également le concept de deployment freeze (gel de déploiement) — un arrêt complet des déploiements en production, typique pour la période des fêtes (vacances de Noël, Black Friday). Pendant cette période, même les hotfixes sont bloqués à moins qu'ils ne soient liés à la sécurité. Le deployment freeze dure généralement 1 à 2 semaines et est coordonné au niveau de l'entreprise.

Quand introduire un gel et combien de temps il dure

Le moment optimal pour introduire un feature freeze est après la finalisation du code, lorsque toutes les fonctionnalités planifiées sont fusionnées et en cours de QA. Le moment exact dépend du cycle de mise en production : pour un sprint de deux semaines, le feature freeze est introduit 3 à 4 jours avant la date de mise en production ; pour une mise en production mensuelle, 7 à 10 jours avant. Code freeze est introduit 24 à 48 heures avant l'heure planifiée de compilation du build de mise en production.

La durée du gel doit être le minimum suffisant pour stabiliser le code. Un gel trop long (plus de 2 semaines) démotivé l'équipe et crée une accumulation de fonctionnalités non fusionnées, chacune augmentant le risque de conflits après la levée du gel. Un gel trop court (moins de 24 heures pour un feature freeze) ne laisse pas assez de temps pour des tests et des corrections approfondis.

La pratique recommandée est de définir le gel non pas par date calendaire mais par l'état de la base de code. Le feature freeze est introduit lorsque le nombre de bugs ouverts pour la mise en production dépasse un seuil (par exemple, 10 bugs critiques). Code freeze — lorsque le build réussit les tests de fumée et la suite de régression. Time-based freeze (date fixe) reste la norme pour les industries réglementées (fintech, medtech) où la date de mise en production est approuvée par un régulateur.

Automatisation des gels via CI/CD et Git

Le contrôle manuel des gels est une source d'erreurs : un développeur pourrait accidentellement fusionner un PR qui devrait attendre la levée du gel. L'automatisation résout ce problème via les règles de protection de branches Git et les pipelines CI/CD. Chez le fournisseur Git (GitHub, GitLab, Bitbucket), des règles sont configurées pour bloquer les fusions dans la branche de mise en production sans un tag spécial ou l'approbation du release manager.

Pipeline CI/CD vérifie le statut du gel avant de compiler le build. Dans Jenkins, GitLab CI ou GitHub Actions, une étape est ajoutée qui lit un fichier de configuration avec le calendrier des gels et rejette les builds si la date actuelle tombe dans la période de gel. Une alternative est un feature flag dans le panneau d'administration qui bloque le déploiement en production.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze is active. PR blocked." && exit 1

Le script d'exemple freeze-check.js lit un JSON avec le calendrier des gels depuis la racine du dépôt. Si la date actuelle tombe dans l'intervalle entre start_date et end_date pour la branche spécifiée, le pipeline échoue avec un message de statut du gel. Git branch protection ajoute une deuxième barrière : même si le pipeline ne s'est pas déclenché, la règle ne permet pas de fusionner le PR sans approbation.

Erreurs courantes lors de l'implémentation des gels

La première erreur est un gel sans critères clairs de levée. L'équipe gèle le code mais ne définit pas les conditions à remplir pour dégeler : zéro bug critique, suite de régression réussie, approbation du product manager. Sans critères, le gel peut s'éterniser pendant des semaines. La définition de fin pour le gel doit être documentée et connue de chaque développeur.

La deuxième erreur est trop d'exceptions au gel. Chaque exception (« ce PR n'est pas une fonctionnalité, c'est de la dette technique ») brouille la limite du gel. Si les exceptions dépassent 20 % du flux normal de PR, le gel ne fonctionne pas. L'équipe renomme simplement les fonctionnalités en corrections de bugs pour contourner le blocage.

La troisième erreur est d'ignorer les release candidates. Si l'équipe ne construit pas de builds candidats de mise en production et déploie directement en production après le code freeze, le sens du gel est perdu : les bugs sont découverts par les utilisateurs. Le release candidate doit être construit avant le code freeze, testé par le QA et en staging, et ce n'est qu'après confirmation de la qualité que le code freeze est introduit.

La quatrième erreur est le facteur humain dans le contrôle manuel. Un développeur pourrait oublier de vérifier le statut du gel avant la fusion, un release manager pourrait manquer une notification. La seule solution fiable est le blocage automatique au niveau du fournisseur Git ou du CI/CD, éliminant l'erreur humaine.