DevOps : comment l’automatisation améliore la livraison logicielle

Une mise à jour logicielle peut prendre du retard pour des raisons qui n’ont rien à voir avec la difficulté du code : une configuration à refaire, une validation oubliée ou une personne indispensable indisponible. Le DevOps vise à rapprocher développement et exploitation pour mieux gérer ces passages de relais. L’automatisation permet de rendre les étapes répétitives plus fiables et plus faciles à examiner.

L’objectif n’est pas de mettre en production à tout prix. Il s’agit de livrer des changements utiles avec des contrôles, des retours d’information et des moyens de reprise adaptés au service et à ses utilisateurs.

Que signifie automatiser en DevOps ?

Le DevOps associe des pratiques de collaboration et d’amélioration continue à une responsabilité partagée sur le développement, la livraison et l’exploitation. L’automatisation prend en charge certaines tâches reproductibles : construire l’application, exécuter des tests ou préparer un environnement, par exemple. Les équipes restent responsables des priorités, de l’évaluation des risques, des exceptions et des incidents.

Pour une organisation qui achète ou développe un produit numérique, cette approche peut réduire la dépendance à des procédures de mise en production peu documentées et révéler plus tôt les blocages. Les résultats dépendent notamment de la qualité des tests, de l’architecture existante et du temps consacré à maintenir les processus automatisés.

Du code à la production : le rôle du pipeline CI/CD

Un pipeline relie les étapes qui transforment une modification de code en version livrable. Dans un scénario simple, chaque changement déclenche une construction et des tests. Le système produit ensuite un paquet versionné et le déploie dans un environnement de test. Si les contrôles sont concluants, une personne habilitée peut autoriser la mise en production, puis l’équipe surveille le service.

• Intégration continue (CI) : les développeurs intègrent fréquemment leurs modifications et utilisent des constructions et tests automatisés pour détecter les problèmes rapidement. Selon le guide DORA sur l’intégration continue, disposer d’un outil de construction ne suffit pas : la fréquence d’intégration et le traitement des échecs comptent aussi.
• Livraison continue : les changements restent prêts à être livrés de façon maîtrisée ; une décision ou une validation peut précéder leur mise en production.
• Déploiement continu : les changements qui passent les contrôles requis sont déployés automatiquement en production. Le glossaire de Google Cloud précise la distinction avec la livraison continue.

Le déploiement automatique en production n’est pas obligatoire pour adopter le DevOps. En présence de modifications complexes des données ou d’un risque d’exploitation élevé, une validation humaine peut rester pertinente, même si le reste du processus est largement automatisé.

Les usages qui apportent une valeur concrète

Construire, tester et garder une trace

Une construction reproductible limite les manipulations manuelles nécessaires pour préparer une version. Des tests automatisés peuvent vérifier les fonctions importantes à chaque changement et signaler plus tôt certaines régressions. Le pipeline peut également conserver la version du paquet, les résultats des contrôles et les validations associées. Ces traces facilitent les investigations, sans garantir l’absence de défauts.

Rendre les environnements plus cohérents

L’« infrastructure as code » consiste à décrire des configurations d’infrastructure dans des fichiers exploitables par des outils et pouvant être relus et versionnés. Cette pratique favorise la reproductibilité et peut réduire les écarts dus aux configurations manuelles. Elle exige néanmoins des contrôles d’accès, des revues et de la maintenance : les fichiers ne suppriment pas, à eux seuls, tous les écarts. Voir la présentation de l’infrastructure as code par Google Cloud.

Intégrer la sécurité et préparer la reprise

Une équipe peut vérifier automatiquement les dépendances vulnérables ou la présence de secrets exposés, puis définir qui examine les alertes et quelles anomalies bloquent une livraison. Les recommandations du NIST sur la sécurité de la chaîne d’approvisionnement logicielle dans les pipelines CI/CD décrivent des pistes d’intégration. Les contrôles automatiques complètent les revues de sécurité et la réponse aux incidents ; ils ne les remplacent pas.

Pour une version plus risquée, un déploiement limité à une partie des utilisateurs permet d’observer les indicateurs du service avant une diffusion plus large. Il faut également tester la reprise. Revenir à une ancienne version du code ne suffit pas forcément à annuler une modification de base de données ou à restaurer des données modifiées. Les recommandations AWS sur la compatibilité des schémas invitent à prévoir et à tester la coexistence des anciennes et nouvelles versions.

Comment évaluer les progrès ?

Établissez d’abord une situation de référence pour une application ou un service, puis observez son évolution. Les indicateurs de livraison logicielle DORA proposent cinq mesures complémentaires :

• Délai de changement : temps entre l’enregistrement d’une modification et son déploiement en production.
• Fréquence de déploiement : rythme auquel les changements arrivent en production.
• Délai de récupération après un déploiement en échec : temps nécessaire pour rétablir le service.
• Taux d’échec des changements : part des déploiements nécessitant une intervention immédiate.
• Taux de déploiements correctifs non planifiés : part des déploiements effectués pour corriger des incidents en production.

Ces indicateurs se lisent ensemble et dans leur contexte. Déployer davantage n’est pas nécessairement un progrès si les échecs ou les corrections augmentent. Plutôt que de classer des équipes aux contraintes différentes, cherchez à comprendre l’évolution d’un même service. Ajoutez, selon ses objectifs, des indicateurs visibles par les utilisateurs, comme les erreurs ou la disponibilité.

Par où commencer avec son équipe ou un partenaire ?

1. Cartographier une livraison : repérer les tâches manuelles, les attentes, les passages de relais et la procédure de reprise. Le guide DORA sur la cartographie des flux recommande d’examiner la livraison normale comme le rétablissement après incident.
2. Choisir un blocage précis : par exemple, automatiser la construction et quelques tests fiables d’une application avant d’étendre le pipeline.
3. Définir les contrôles : préciser les accès, les validations, les vérifications de sécurité, les contacts d’escalade et une méthode de reprise testée.
4. Mesurer puis ajuster : comparer les tendances de livraison et d’incident à la situation initiale, examiner les fausses alertes et entretenir les tests au fil des changements.

Avant de choisir un partenaire de livraison, clarifiez la propriété du code et de la configuration du pipeline, les accès nécessaires, le transfert de connaissances et la prise en charge des alertes et de la maintenance. Convenez du périmètre, des responsabilités et des critères de réussite avant de sélectionner les outils. Ces questions aident aussi plusieurs partenaires à coordonner leurs contributions sans imposer un modèle unique à toutes les organisations.

À retenir

L’automatisation DevOps apporte surtout de la valeur lorsqu’elle lève un obstacle réel à la livraison tout en préservant les décisions humaines importantes. Les services d’Altweeb en développement logiciel, conseil technologique et renfort d’équipe peuvent servir de point de départ pour discuter des besoins de livraison et des compétences nécessaires. Le périmètre adapté dépend de l’application, de l’équipe en place et des résultats recherchés.

Pour approfondir ce sujet, découvrez aussi Développement logiciel et de produits numériques.