6 min de lecture
À propos de notre modèle de produit et de livraison
Aperçu du produit / projet
Freya Fusion est une plateforme technologique réglementaire avancée qui s'appuie sur l'IA et des solutions Cloud-based pour simplifier les processus de conformité. Ses principales caractéristiques comprennent un Cloud réglementaire axé sur l'IA pour une supervision intelligente, une composabilité des données, des contenus, des applications et des interfaces utilisateur garantissant la flexibilité, ainsi que des processus réglementaires harmonisés grâce à une planification transversale. La plateforme propose également des solutions d'automatisation intégrées, un graphe de connaissances pour des analyses structurées, et une interface utilisateur conversationnelle pour faciliter les interactions. Conçue pour offrir une efficacité optimale, Freya Fusion associe des technologies de pointe à une expertise réglementaire afin de simplifier les flux de travail complexes liés à la conformité.
Écosystème actuel de processus et de livraison
Méthodologie agile et outils
Chez Freya Fusion, nous utilisons la méthodologie Agile intégrée aux pratiques DevSecOps pour garantir la sécurité, la conformité et l'efficacité, du code au déploiement. Dans notre cadre Agile, les fonctionnalités constituent les principaux éléments de travail de publication. Plusieurs fonctionnalités sont regroupées et validées ensemble pour former un candidat à la publication (RC), ce qui garantit une livraison de valeur progressive et contrôlée.
Intégrations Azure DevOps (ADO) et de plug-ins
Vue d'ensemble du pipeline CI/CD
Les pipelines d'intégration continue et de déploiement continu (CI/CD) automatisent le processus de livraison logicielle, du développement à la production, garantissant des publications plus rapides, une qualité constante et une réduction des erreurs manuelles.
Intégration continue (CI) – La phase de construction et de test utilisée par l'équipe de sprint
- Validation du code (Commit) : les développeurs envoient les modifications vers un dépôt partagé (par exemple, Azure Repos, GitHub).
- Construction automatisée : le pipeline compile le code, résout les dépendances et regroupe les artefacts.
- Tests automatisés : des tests unitaires, des tests d'intégration et des analyses de sécurité (SAST/DAST) sont exécutés pour détecter les problèmes en amont.
- Stockage des artefacts : les versions validées sont stockées dans des dépôts
Déploiement continu (CD) – La phase de publication utilisée par l'équipe de déploiement
- Environnements étagés : le code progresse à travers DevSecOps → SQA → Préprod → Production avec des points de contrôle d'approbation.
- Déploiements automatisés : le déploiement s'effectue via des pipelines de publication avec un temps d'indisponibilité minimal
- Contrôles post-déploiement : tests de bon fonctionnement automatisés, surveillance des performances et mécanismes de restauration en place régis par des SOP.
Types de publications : Majeure, Mineure, Correctif, Correctif d'urgence (Hotfix)
Les publications sont classées en versions majeures, mineures, correctifs ou correctifs d'urgence selon l'intention et les fonctionnalités proposées dans cette version.
- Majeure – Désigne une version initiale ou une version dont les fonctionnalités modifient le comportement sans rétrocompatibilité
- Mineure – Désigne la publication d'une nouvelle fonctionnalité avec rétrocompatibilité ainsi que des améliorations apportées aux fonctionnalités existantes
- Correctif (Patch) – Désigne la publication groupée de corrections de bugs, de mises à jour de sécurité et de petites améliorations avec rétrocompatibilité
- Correctif d'urgence (Hotfix) – Désigne une version d'urgence visant à résoudre des problèmes critiques signalés en production dans la version déployée.
Indicateurs clés importants
Explication des quatre métriques DORA :
Conformément aux normes du secteur, quatre métriques clés doivent être suivies et optimisées pour assurer le succès des organisations.
- Délai de mise sur le marché / Lead Time (vitesse à laquelle nous livrons les logiciels en production)
- Fréquence des déploiements (la fréquence à laquelle vous effectuez des mises en production).
- Taux d'échec des modifications (la fréquence des échecs de déploiement).
- Temps moyen de restauration (MTTR) (la rapidité avec laquelle vous corrigez les pannes).
Le délai de mise en œuvre est l'un des quatre indicateurs clés de recherche et d'évaluation DevOps (DORA). Il mesure le temps nécessaire pour que les modifications de code passent du commit au déploiement en production, reflétant l'efficacité de votre processus de livraison de logiciels. Cet indicateur mesure la durée moyenne entre le moment où une modification de code est validée et celui où elle est déployée avec succès en production.
Le délai de mise en œuvre indique :
- la vitesse de livraison et l'efficacité des processus.
- Des délais plus courts sont corrélés à des boucles de rétroaction plus rapides et à une plus grande agilité.
La fréquence des déploiements permet de suivre la fréquence à laquelle les modifications de code sont déployées avec succès en production. Elle reflète la rapidité et la cohérence de votre processus de livraison de logiciels.
La fréquence des déploiements indique :
- L'agilité de l'équipe et la maturité des processus.
- Des déploiements fréquents réduisent les risques en permettant des modifications plus petites et progressives (par opposition à des versions importantes et rares).
- Corrélation avec des boucles de rétroaction plus rapides et une plus grande satisfaction client.
Le temps moyen de restauration (MTTR) mesure le temps moyen nécessaire pour rétablir le service après une panne (par exemple, une interruption, une baisse de performance ou un bug). Il reflète la résilience de votre équipe et son efficacité en matière de gestion des incidents.
Le MTTR indique :
- Minimise les temps d'arrêt et l'impact sur les utilisateurs.
- Un MTTR élevé indique un débogage lent, une surveillance insuffisante ou des processus de restauration inefficaces.
- Corrélation avec la confiance des clients, les coûts opérationnels et le stress de l'équipe.
Le taux d'échec des modifications (CFR) mesure le pourcentage de déploiements qui entraînent des pannes en production, nécessitant des interventions correctives (par exemple, des retours en arrière, des correctifs rapides ou des rustines). Il reflète la stabilité et la fiabilite de votre processus de publication.
Le CFR indique :
- Indique la fréquence à laquelle les déploiements introduisent des défauts (bugs, pannes, problèmes de performance).
- Un CFR élevé suggère des tests insuffisants, une surveillance inadéquate ou des pratiques de publication risquées.
- Corrélation avec l'épuisement professionnel de l'équipe, la confiance des clients et les coûts opérationnels.
| Indicateur | Définition | Formule |
| Délai de mise en œuvre | Temps moyen pour réaliser une fonctionnalité | Somme du délai de livraison / Nombre de fonctionnalités |
| Fréquence des déploiements | Fréquence de déploiement du code en production. | Nombre total de déploiements / Nombre de mois |
| Taux d'échec des changements (CFR) | Pourcentage de déploiements entraînant un échec. | Nombre de modifications échouées ÷ Nombre total de modifications × 100. |
| Temps moyen de restauration (MTTR) | Temps moyen nécessaire pour rétablir le service après une panne. | Somme des temps de restauration ÷ Nombre de pannes (problème opérationnel / bug / problème de données) |
Mesures de soutien supplémentaires :
- Travaux en cours (WIP) : Mesure le nombre de tâches non terminées (par exemple, modifications de code, fonctionnalités, bugs) actuellement dans le processus. Cette mesure aide à évaluer les goulots d'étranglement et la nécessité de diviser la fonctionnalité ou l'user story
- Temps de cycle : Temps écoulé entre le début du travail (par exemple, la création d'un ticket) et sa fin
- Nombre de demandes de tirage (Pull Requests) : mesure qui suit le nombre de PR créées, fusionnées ou rejetées sur une période donnée (par exemple, chaque jour, chaque semaine ou chaque mois). Elle aide les équipes à évaluer la productivité des développeurs, l'efficacité de la collaboration et les goulots d'étranglement du flux de travail.
- Incidents clients : Nombre d'incidents de production signalés par les clients indiquant la qualité des tests internes
- Bugs ouverts : Cette mesure suit le nombre de défauts non résolus (bugs) dans votre système à un moment donné. Elle aide à mesurer la qualité du logiciel, la dette technique et l'efficacité de l'équipe dans la résolution des problèmes.
- Bugs ouverts de longue date : Les bugs ouverts de longue date sont des défauts qui restent non résolus pendant une période prolongée (généralement 30 jours ou plus). Leur suivi permet d'identifier les inefficacités de processus, les lacunes de priorisation et la dette technique
- Bugs reportés : Il s'agit de défauts qui ont été reconnaissables mais intentionnellement reportés pour être résolus ultérieurement. Bien que le report puisse être une stratégie légitime, des reports excessifs peuvent indiquer une accumulation de dette technique, des problèmes de priorisation ou des inefficacités de processus.
- Statut de l'intégration continue (CI) : Cette mesure surveille la stabilité et la fiabilité de votre pipeline d'intégration continue (CI) en suivant le taux de réussite et d'échec des builds et des tests automatisés. Un système d'intégration continue sain est essentiel pour obtenir des commentaires rapides, des livraisons de haute qualité et une bonne productivité des développeurs
- Statut du déploiement continu (CD) : Cette mesure surveille la stabilité, la vitesse et le taux de réussite de votre déploiement automatisé. Un système de déploiement continu sain garantit des livraisons fiables, fréquentes et à faible risque.
- Tests d'intégration : Les tests d'intégration valident que des modules, services ou systèmes développés indépendamment fonctionnent correctement lorsqu'ils sont combinés. Il s'agit d'une phase essentielle en DevOps pour détecter les problèmes avant qu'ils n'atteignent la production.
- Suite de surveillance de la production : Ensemble d'outils et de pratiques pour suivre la santé du système, détecter les anomalies et résoudre les problèmes en temps réel pour les applications s'exécutant en production. C'est indispensable pour les équipes SRE, DevOps et Opérations afin de maintenir la disponibilité, les performances et la satisfaction des utilisateurs.
Pourquoi les mesures comptent dans une organisation prospère
Le suivi des mesures DevOps et opérationnelles (telles que DORA, le délai de livraison, la fréquence des déploiements, le MTTR, le CFR, les alertes de surveillance, etc.) fournit des informations exploitables qui favorisent la réussite commerciale, l'excellence technique et un avantage concurrentiel.
- Accélérer la mise sur le marché
- Indicateurs : Délai de réalisation, Fréquence de déploiement, Cycle de vie
- Impact :
- Des versions plus rapides → Répondre plus rapidement aux demandes du marché.
- Des boucles de rétroaction plus courtes → Innover plus rapidement que la concurrence.
- Améliorer la qualité et la fiabilité des logiciels
- Indicateurs : Taux d'échec des modifications (CFR), temps moyen de récupération (MTTR), bugs ouverts
- Impact :
- Moins d'incidents de production → Meilleure satisfaction client.
- Résolution plus rapide des incidents → Minimiser les pertes de revenus
- Réduire les coûts et le gaspillage
- Indicateurs : Statut CI du build, échecs des tests d'intégration, tests instables
- Impact :
- Détection précoce des bugs → Moins coûteux à corriger en phase de développement qu'en production
- Pipelines efficaces → Réduction des coûts de cloud et de calcul
- Améliorer la productivité et le moral de l'équipe
- Indicateurs : Temps de cycle des PR, limites des travaux en cours (WIP), taux de réussite des déploiements
- Impact :
- Moins de goulots d'étranglement → Les développeurs passent plus de temps à coder et moins à attendre.
- Vérifications automatisées → Réduction de l'épuisement professionnel lié aux tâches manuelles répétitives.
- Aligner DevOps sur les objectifs commerciaux
- Indicateurs : livraison des unités commercialisables, taux d'incidents clients, engagements de disponibilité
- Impact :
- Associe les efforts d'ingénierie au chiffre d'affaires, à la croissance de la base d'utilisateurs et à la fidélisation.
- Prise de décision fondée sur les données
- Indicateurs : tendances du MTTR, vieillissement des anomalies, fréquence des déploiements
- Impact :
- Donner la priorité aux améliorations à fort impact
- Justifier les investissements dans l'automatisation, la formation ou les outils par des preuves de retour sur investissement (ROI).
Résumé :
En automatisant le suivi et l'optimisation de ces indicateurs clés, les organisations peuvent obtenir des avantages significatifs, notamment :
- Décisions fondées sur les données – Tirez parti d'informations exploitables pour guider votre stratégie et vos investissements.
- Excellence en ingénierie – Favoriser l'amélioration continue des pratiques de développement et d'exploitation.
- Compétitivité sectorielle – S'aligner sur les meilleures références du marché (ou les dépasser).
- Réussite des clients – Proposer des solutions fiables et de haute qualité qui répondent aux attentes des utilisateurs.
- Gouvernance et leadership – Assurer la transparence et la responsabilité à tous les niveaux.
Cette approche structurée garantit des processus plus intelligents, de meilleures performances et une croissance commerciale soutenue.
Références
- Accelerate par Forsgren, Humble & Kim
- Documentation Azure DevOps
- Rapports de recherche et d'évaluation DevOps (DORA)
