• Objectif : assurer une maintenance et des mises à jour de version continues et programmées pour une série de produits de technologie financière (PMS), améliorant ainsi la fiabilité du système (correction des bogues) et la disponibilité des fonctionnalités.
• Résultats : livraison de plus de 300 versions par an dans le respect du budget et du calendrier.
• Budget: R&D, +14’000 jours/homme/an.
• Personnel : 20 personnes à temps plein, +150 personnes environ 30% d’activité.
• Calendrier : activité à temps plein pendant 12 ans.
• Personnel : Equipe de 4 delivery managers, 5 ingénieurs DevOps, +10 team leads en développement et Q&A, 1 spécialiste en documentation.

Objectifs atteints

• Supervision pratique du contrôle des sources et des processus de construction pendant une demi-décennie – des processus solides toujours en place 20 ans plus tard.
• Une expérience de 12 ans dans l’orchestration de livraisons de logiciels de bout en bout, allant de correctifs mineurs à des mises à niveau de versions majeures.
• Facilitation des lancements de produits alpha et bêta sur le marché des consommateurs.
• Exécution des versions candidates, qui constituent la dernière étape d’assurance qualité avant le déploiement à grande échelle.
• Leadership et mentorat d’une équipe de 4 (quatre) delivery managers.
• Engagement collaboratif avec des équipes interfonctionnelles, y compris DevOps, le développement de logiciels, l’assurance qualité et la gestion des produits (+150 personnes).
• Administration diligente des contraintes budgétaires, du paysage des risques, des jalons de contenu, des calendriers de livraison et des rapports aux parties prenantes.
• La priorisation de diverses facettes de l’excellence opérationnelle, y compris la normalisation des processus, la stabilité des systèmes, la qualité des logiciels, les mesures de cybersécurité, la compatibilité des logiciels tiers, les améliorations continues et les canaux de communication efficaces.
• Un historique constant de livraison de plus de 150 versions de logiciels par an, en respectant à la fois le budget et les délais de livraison.
• Utilisation de Bamboo et de Jenkins pour orchestrer les builds incrémentaux et complets quotidiens, couvrant à la fois les plateformes Unix (IBM, Solaris, Redhat) et Windows.
• Exécution quotidienne d’installations de produits, de mises à jour de versions et d’un large éventail de suites de tests, à la fois manuels et automatisés.
• Conservation de la documentation manuelle et générée par la machine afin de garantir des documents de référence complets et à jour.

Risques et difficultés

• Erreurs de configuration : Incohérences dans les configurations logicielles d’un environnement à l’autre entraînant des comportements imprévus.
  • Stratégie d’atténuation : Utilisez des outils de gestion de la configuration et maintenez des fichiers de configuration contrôlés par version. Veillez à ce que des protocoles stricts soient appliqués aux changements de configuration.
• Régression du code: Les nouveaux déploiements de code peuvent, par inadvertance, briser des fonctionnalités existantes.
  • Stratégie d’atténuation : Mettez en œuvre des tests de régression automatisés dans le cadre du pipeline CI/CD afin de détecter ces problèmes avant qu’ils n’atteignent la production.
• Dépendances non résolues : L’absence de prise en compte des composants logiciels interdépendants peut bloquer ou interrompre la publication.
  • Stratégie d’atténuation : Cartographie des dépendances et vérification automatisée des dépendances au cours du processus de construction.
• Erreurs de migration des données : Risque de corruption ou de perte de données au cours du processus de mise en production, en particulier s’il implique des modifications du schéma de la base de données.
  • Stratégie d’atténuation : Versionnement de la base de données, sauvegardes automatisées et contrôles complets de validation des données. Séparez les modifications de la base de données des modifications de l’application.
• Défauts de retour en arrière : Impossibilité de revenir à une version stable du logiciel au cas où la nouvelle version serait défectueuse.
  • Stratégie d’atténuation : Procédures automatisées de retour en arrière préconfigurées, associées à une surveillance en temps réel des déclencheurs.
• Vulnérabilités en matière de sécurité: Les nouvelles versions peuvent entraîner des vulnérabilités du système si elles ne sont pas correctement contrôlées.
  • Stratégie d’atténuation : Intégrez des outils d’analyse de la sécurité dans le pipeline CI/CD et adhérez à des pratiques de codage sécurisées.
• Manque de communication avec les parties prenantes : Une mauvaise communication avec les parties prenantes peut conduire à des attentes mal alignées et au chaos lors de la mise en production.
  • Stratégie d’atténuation : Maintenez un tableau de bord des versions accessible à toutes les parties prenantes et mettez en place des notifications automatisées pour les étapes clés de la version. Utilisation de portes d’étape et de critères de sortie dans le cadre du cycle de développement durable.
• Inadéquation des talents et des compétences : Les membres de l’équipe peuvent ne pas avoir les compétences nécessaires pour gérer efficacement des versions complexes.
  • Stratégie d’atténuation : Évaluation des compétences et programmes de formation ciblés, éventuellement complétés par des consultants externes pour les rôles spécialisés. Utilisez des méthodes agiles telles que la programmation en binôme et les révisions de code.
• Dépassement des délais de codage : Le dépassement des délais de codage peut avoir un effet en cascade et perturber les phases ultérieures telles que les tests, l’intégration et le déploiement. Cela amplifie les risques associés à des délais de livraison serrés et peut conduire à une qualité compromise ou à des opportunités de marché manquées.
  • Stratégie d’atténuation : Mettez en place un système de calcul des coûts par activité en fonction du temps (TDABC) afin d’obtenir des informations détaillées sur la durée des tâches et d’identifier les goulets d’étranglement. Utilisez l’analyse prédictive pour prévoir les risques liés aux délais et réaffecter les ressources de manière dynamique. Établissez une « zone tampon » dans le calendrier du projet, spécialement conçue pour absorber ces dépassements sans affecter la date de livraison globale.
• Des délais de livraison serrés : Des délais serrés peuvent conduire à des processus précipités, compromettant la qualité du code, l’exhaustivité des tests et la communication avec les parties prenantes. Cette approche peut exacerber d’autres risques opérationnels, car il n’y a peut-être pas assez de temps pour résoudre les problèmes avant la publication.
  • Stratégie d’atténuation : Mettez en œuvre des méthodologies agiles en mettant l’accent sur des sprints limités dans le temps et sur l’identification précoce des risques. Utilisez des flux de développement et de test parallèles pour optimiser l’utilisation du temps. En outre, des « salles de guerre » ad hoc peuvent être créées pour les versions cruciales afin de gérer en temps réel les complexités sensibles au facteur temps.
• Modifications fréquentes de l’étendue du projet : Des modifications constantes des objectifs ou des fonctionnalités du projet peuvent entraîner une mauvaise affectation des ressources, des retards dans les délais et une complexité accrue. Cette situation est particulièrement précaire dans les contextes Agile, où le champ d’application est conçu pour être flexible, mais dans le cadre d’itérations limitées.
  • Stratégie d’atténuation : Utilisez un comité de contrôle des changements (CCB) impliquant les principales parties prenantes pour évaluer et approuver les changements de portée. Mettez en œuvre un système de gestion du carnet de commandes dynamique mais contrôlé, dans lequel les modifications sont regroupées et classées par ordre de priorité pour les sprints suivants, plutôt que de perturber le travail en cours. En outre, tirez parti des bascules de fonctionnalités pour intégrer les changements sans modifier la base de code principale.
• Défaillances des fournisseurs ou des tiers : La dépendance à l’égard de services ou de bibliothèques externes peut entraîner une instabilité si ces composants tombent en panne ou changent de manière inattendue.
  • Stratégie d’atténuation : Diversifiez les sources de dépendance et mettez en place un cadre de gestion des risques liés aux fournisseurs. Procédez à des audits réguliers de la fiabilité et de la sécurité des services tiers.
• Documentation incomplète : Une documentation mal entretenue ou incomplète peut entraver le dépannage, l’intégration des nouveaux membres de l’équipe et le développement futur.
  • Stratégie d’atténuation : Mettez en œuvre une approche de type « Documentation as Code » dans laquelle la documentation est mise à jour en même temps que les modifications du code. Effectuez des révisions périodiques de la documentation.
• Résistance culturelle au changement : L’opposition des membres de l’équipe, à la fois offshore et onshore, à l’adoption de nouveaux outils ou processus peut ralentir le cycle de publication.
  • Stratégie d’atténuation : Des pratiques de gestion du changement telles que des ateliers internes, des essais pilotes et une communication transparente pour faciliter la transition.
• Défauts d’audit et de conformité : Le non-respect des normes et réglementations du secteur peut entraîner des répercussions juridiques et une perte de confiance.
  • Stratégie d’atténuation : Intégrez des contrôles de conformité dans le pipeline CI/CD et effectuez des audits internes et externes réguliers.
• Couverture insuffisante des tests : Des tests inadéquats – qu’il s’agisse de tests unitaires, d’intégration ou de bout en bout – peuvent entraîner l’apparition de bogues, de vulnérabilités ou de problèmes de performance non détectés dans le produit publié. Cela présente des risques importants, allant d’une baisse de la satisfaction des utilisateurs à des conséquences juridiques dans les cas extrêmes.
  • Stratégie d’atténuation : Utilisez le développement piloté par les tests (TDD) pour intégrer les tests dans le processus de développement lui-même. Exploitez les cadres de tests automatisés pour maximiser la couverture sans augmenter proportionnellement le temps et la main-d’œuvre. Établissez des indicateurs clés de performance (ICP) spécifiques pour la couverture des tests et les mesures de qualité, en faisant de ces ICP un aspect central des critères de publication.