Déploiement isolé d’une application : la principale cause d’échec

1. Le test valide l’application, pas son périmètre

C’est une scène familière dans beaucoup de DSI. Une application a été spécifiée, développée, recettée. Elle passe tous ses tests. Elle est déployée en production dans une fenêtre validée. Et le lendemain matin, un flux ne passe plus, un batch de nuit s’est arrêté, un service renvoie une erreur.

On cherche alors le défaut dans l’application déployée. On ne le trouve pas, parce qu’il n’y est pas. L’application seule fonctionne exactement comme prévu. Ce qui a cassé, c’est ce qui la relie aux autres.

C’est la cause d’échec la plus fréquente en production : non pas le contenu du déploiement, mais son périmètre.

2. Le mécanisme du déploiement partiel

Une application d’entreprise n’est plus une brique isolée. Elle expose des interfaces, consomme des flux, partage des référentiels, alimente des traitements en aval. Chaque lien de ce type est un “contrat implicite” entre deux applications : un format d’échange, une structure de données, une séquence attendue.

Or les évolutions de ces applications ne sortent pas de la même chaîne. Elles proviennent de branches de développement distinctes, portées par des équipes différentes, avec des calendriers différents. Quand une évolution modifie un “contrat d’interface”, elle est presque toujours accompagnée de l’évolution correspondante côté application appelante, mais dans une autre livraison.

Déployer l’une sans l’autre, c’est mettre en production la moitié du contrat. Techniquement, chaque livraison est valide. Fonctionnellement, l’ensemble est incohérent.

C’est pourquoi le déploiement synchronisé a cessé d’être une bonne pratique pour devenir une contrainte structurelle. Ce n’est pas une question de rigueur : c’est une conséquence directe de l’augmentation des interdépendances applicatives.

3. La recette ne prouve rien sur la production

Dans la quasi-totalité des organisations, les développeurs n’ont pas accès à la production. Ils déploient en environnement de test ; la mise en production relève d’une autre équipe, avec d’autres outils et d’autres procédures.

Cette séparation est saine, elle protège la production. Mais elle crée un angle mort que personne ne détient : une application validée isolément en recette ne dit rien de son comportement en production synchronisée. L’équipe de développement valide un périmètre applicatif. L’équipe d’exploitation exécute un périmètre de déploiement. Ce ne sont pas les mêmes objets, et la cohérence entre les deux n’appartient à personne.

Le défaut n’est donc pas dans le code, ni dans les procédures d’exploitation. Il est dans la couture entre les deux, précisément là où seule une direction informatique a le pouvoir d’intervenir.

4. Les dépendances, un problème d’échelle

La synchronisation, c’est une affaire de coordination et donc de méthode. Elle ne résiste pas aux chiffres.

Dans une organisation type, on compte environ cent développeurs pour cinq personnes en exploitation. Chez certains clients, une équipe de moins de dix personnes prend en charge plusieurs milliers d’applications et plusieurs milliers de déploiements par mois.

À ce volume, la question n’est plus celle de la compétence des équipes. C’est une question de charge. Aucune équipe de cette taille ne peut tenir à la main la cartographie des dépendances de plusieurs milliers d’applications, la mettre à jour en continu, et en déduire à chaque fenêtre le périmètre exact à déployer ensemble. Ce n’est pas un problème de discipline, c’est un problème d’échelle. Et un problème d’échelle ne se résout pas par de la rigueur, mais par de l’outillage.

5. Le cas où l’échec n’est pas rattrapable

Un déploiement raté est généralement récupérable : rollback, correctif à chaud, nouvelle fenêtre.

Sauf quand la fenêtre est légale. Certaines applications doivent être en production à une date fixe, imposée par l’entrée en vigueur d’un texte réglementaire. Il n’y a pas de report possible, pas de fenêtre suivante, et le rollback ne résout rien : revenir à l’état antérieur, c’est précisément se mettre en défaut.

Dans ce contexte, un déploiement incomplet ne coûte pas du temps d’exploitation. Il coûte de la conformité.

6. Où en est votre organisation ?

La capacité à déployer de façon synchronisée se lit sur une échelle de maturité, dont chaque marche correspond à un objet déployé différent :

• Le script. On automatise des gestes, un par un. L’orchestration reste humaine.
• Le déploiement de fichiers. On sait porter un ensemble de fichiers vers une cible, de façon reproductible.
• Le déploiement d’applications. L’objet déployé n’est plus un fichier mais une application, avec ses composants et ses prérequis.
• Le déploiement vers des environnements. L’application est déployée vers une cible décrite, et non vers une machine.
• L’orchestration de déploiements simultanés. Plusieurs applications interdépendantes sont déployées comme un seul événement, avec un point de retour arrière commun.

Le franchissement décisif se situe entre la marche 3 et la marche 5. En dessous, la synchronisation reste une intention portée par des personnes. Au-dessus, elle devient une propriété du système.

7. Ce que cela implique pour vous

Traiter le déploiement comme une tâche technique, c’est accepter que la cohérence de la production dépende de la vigilance de cinq personnes. Le traiter comme un enjeu de continuité de service, c’est en faire un objet piloté, mesuré et outillé.

C’est ce que permet DROPS : déployer comme un événement unique des applications et des releases interdépendantes, avec un retour arrière d’ensemble, sur des plateformes hétérogènes.