Quand chaque déploiement est une histoire différente : le piège de la livraison ad hoc

Vous avez une petite équipe. Cinq ou six personnes peut-être. L'application fonctionne. Les utilisateurs sont contents. Les déploiements ont lieu, mais personne ne parle vraiment de la façon dont ils se font. Un développeur copie des fichiers sur le serveur via FTP. Un autre exécute un script depuis son ordinateur personnel. Un troisième se connecte directement en production et fait des modifications à la volée.

Personne ne se plaint, parce que ça marche la plupart du temps. Jusqu'au jour où ça ne marche plus.

La personne qui « sait déployer » part en congé. Un bug critique doit être corrigé, et personne d'autre ne parvient à reproduire les étapes. Le déploiement prend trois heures au lieu de vingt minutes. Quelqu'un exécute la mauvaise commande SQL sur la base de production. Impossible d'annuler l'opération.

Voici le niveau 1 de maturité de livraison : Ad Hoc. Tout est manuel. Tout est différent à chaque fois. Et tout le processus dépend de qui est disponible, pas de ce qui est documenté ou automatisé.

Le problème de la dépendance individuelle

Le signe le plus évident d'un processus de livraison Ad Hoc est que la connaissance réside dans la tête des gens, pas dans un système partagé. Quand une seule personne détient le savoir du déploiement, cette personne devient un goulot d'étranglement. Si elle est en congé, les déploiements s'arrêtent. Si elle quitte l'entreprise, la connaissance part avec elle.

Même quand une documentation existe, elle est généralement obsolète. Quelqu'un a écrit un README il y a six mois. Depuis, les étapes de déploiement ont changé cinq fois. Personne n'a mis le document à jour. Les nouveaux membres de l'équipe apprennent par essais et erreurs, en demandant à celui qui semble savoir ce qu'il fait.

Le diagramme suivant illustre comment un déploiement ad hoc peut bifurquer vers des chemins imprévisibles, chacun avec ses propres risques :

flowchart TD A[Un développeur lance le déploiement] --> B{Quelle méthode ?} B --> C[FTP des fichiers vers le serveur] B --> D[Exécution d'un script personnel] B --> E[Modification directe en production] C --> F[Fichiers potentiellement incomplets] D --> G[Le script ne fonctionne que sur une machine] E --> H[Risque de mauvaise commande SQL] F --> I[Le déploiement échoue silencieusement] G --> J[Un autre développeur ne peut pas l'exécuter] H --> K[Aucun rollback possible] I --> L[Personne en congé - pas de correctif] J --> L K --> L L --> M[Le déploiement prend des heures]

Ce n'est pas une question d'incompétence. Les petites équipes survivent souvent ainsi parce que les enjeux sont faibles. Mais à mesure que l'équipe grandit, les fissures deviennent visibles. Chaque déploiement devient une nouvelle aventure. Personne ne peut prédire s'il prendra dix minutes ou deux heures.

Déploiement manuel : jamais deux pareils

Dans un environnement Ad Hoc, il n'y a pas de procédure de déploiement standard. Chaque développeur a sa propre méthode. L'un peut se connecter en SSH au serveur, tirer le dernier code et redémarrer le service. Un autre peut télécharger un fichier zip via une interface web. Un troisième peut exécuter un script local qui ne fonctionne que sur sa machine.

Comme il n'y a pas de source unique de vérité, personne ne peut vérifier si le déploiement a été fait correctement. Quand quelque chose échoue, la personne qui déploie commence à tâtonner. Elle essaie différentes commandes, redémarre des services, vérifie les logs, et espère que quelque chose fonctionne. Si elle est bloquée, elle appelle quelqu'un d'autre qui en sait peut-être plus.

Cette approche fonctionne quand vous déployez une fois par mois. Elle devient pénible quand vous devez déployer chaque semaine ou chaque jour. Chaque déploiement comporte le même risque, car le processus n'est jamais affiné. Les erreurs se répètent. Du temps est perdu à redécouvrir les mêmes solutions.

Modifications de base de données sans filet de sécurité

La gestion des bases de données au niveau 1 est particulièrement dangereuse. Les changements de schéma sont appliqués directement sur la base de production. Un développeur se connecte au serveur de base de données, exécute une instruction ALTER TABLE, et espère que rien ne casse.

Il n'y a pas de scripts de migration. Pas de suivi de version. Pas de plan de rollback. Si le changement cause des problèmes, le même développeur doit trouver comment l'annuler, souvent en exécutant une autre commande SQL manuelle qui peut ou non fonctionner.

L'équipe n'a aucun moyen de savoir quelle version du schéma est actuellement en cours d'exécution. Si deux développeurs font des modifications en même temps, les conflits passent inaperçus jusqu'à ce que quelque chose casse. Les données de production peuvent être perdues, corrompues ou laissées dans un état incohérent.

Infrastructure gérée de mémoire

Les serveurs sont configurés manuellement. Quelqu'un se connecte, installe des paquets, configure des services et ajuste les paramètres à la main. La configuration de l'application vit dans des fichiers sur le serveur, pas dans un système de contrôle de version. Si un serveur tombe, l'équipe doit se souvenir de chaque étape nécessaire pour le recréer.

Il n'y a pas d'Infrastructure as Code. Pas de provisionnement automatisé. Pas de processus de configuration reproductible. L'équipe compte sur la mémoire, les post-it et la bonne volonté de celui qui a configuré le serveur d'origine.

Cela fonctionne quand vous avez un ou deux serveurs. Cela devient ingérable quand vous devez passer à l'échelle, récupérer après des pannes ou reproduire des environnements pour les tests.

Pourquoi les équipes restent au niveau 1

Rester au niveau 1 n'est pas un signe de paresse ou de manque de compétence. De nombreuses équipes y restent pour des raisons valables :

  • L'équipe est très petite et les processus manuels sont assez rapides.
  • Les déploiements sont peu fréquents, donc la douleur n'est pas constante.
  • L'application n'est pas critique, donc les échecs ont un faible impact.
  • L'équipe a d'autres priorités qui semblent plus urgentes.

Ces raisons ont du sens à court terme. Mais elles créent des coûts cachés. Chaque déploiement manuel comporte un risque. Chaque étape non documentée crée une dépendance. Chaque modification directe de base de données augmente les risques de perte de données.

Le problème n'est pas que l'équipe fait quelque chose de mal. Le problème est que l'approche actuelle ne passe pas à l'échelle. Quand l'équipe grandit, quand les déploiements deviennent plus fréquents, ou quand l'application devient plus critique, le processus Ad Hoc devient un handicap.

Le premier pas n'est pas d'acheter un outil

Passer au-delà du niveau 1 ne nécessite pas d'outils coûteux ni de pipelines complexes. La première étape est plus simple et plus difficile : reconnaître que le processus actuel n'est pas fiable, et commencer à documenter ce qui se passe réellement lors d'un déploiement.

Avant d'automatiser quoi que ce soit, vous devez savoir ce que vous automatisez. Avant de construire un pipeline, vous devez vous mettre d'accord sur les étapes. Avant d'acheter une plateforme CI/CD, vous devez comprendre votre propre workflow.

Checklist pratique pour sortir de l'Ad Hoc

Si vous reconnaissez votre équipe dans cette description, voici par où commencer :

  • Notez les étapes exactes d'un déploiement, y compris chaque commande et chaque point de décision.
  • Identifiez qui détient les connaissances critiques et ce qui se passe quand cette personne n'est pas disponible.
  • Listez chaque étape manuelle qui pourrait provoquer un échec si elle est mal exécutée.
  • Documentez le schéma actuel de la base de données et comment les modifications sont appliquées.
  • Enregistrez le processus de configuration du serveur, y compris tous les paquets, configurations et dépendances.

Il ne s'agit pas de créer une documentation parfaite. Il s'agit de rendre l'invisible visible. Une fois le processus écrit, vous pouvez voir où se trouvent les risques et où l'automatisation sera réellement utile.

L'essentiel à retenir

La livraison Ad Hoc fonctionne jusqu'au jour où elle ne fonctionne plus. Au moment où un déploiement échoue et que personne ne sait comment le réparer, ou que la personne qui sait est injoignable, le coût des processus manuels devient évident. La voie à suivre ne passe pas encore par les outils ou l'automatisation. Elle consiste à admettre que la méthode actuelle est fragile, et à commencer à écrire ce que vous faites pour pouvoir, un jour, le faire mieux.