Il est aujourd’hui essentiel de penser non seulement en termes de fonctionnalité, mais aussi de service et d'expérience et de répondre aux questions qui en découlent : comment les clients pourront-ils acquérir le produit, s’enregistrer et le configurer, l’utiliser, souscrire plus d’options ou résilier, gérer la sécurité ? Comment seront-ils formés, obtiendront-ils du support ou suivront-ils leur consommation ? Quelle performance est attendue pour une utilisation satisfaisante en termes de disponibilité, de fiabilité et de temps de réponse ?
L'échec de produits innovants découle trop souvent d’une prise en compte insuffisante de la dimension service, la facilité d'utilisation et la qualité de l'expérience globale.
Pour construire une culture de l’innovation centrée sur le client, le service, l’expérience et la performance, les équipes adoptent désormais une approche de mise en œuvre plus incrémentale de l’innovation, en particulier au début du cycle de vie du produit avec le concept de MVP, qui signifie "Produit Minimum Viable".
L'idée est de mettre un produit sur le marché rapidement avec ses fonctionnalités et caractéristiques essentielles, afin de recueillir au plus vite les premières informations sur son utilisation, ainsi que les réactions des clients et des utilisateurs finaux. Cela permet aux équipes d'adapter et d’accélérer l'innovation en se basant sur une connaissance réelle du point de vue qualitatif des clients, sur leur expérience de la fonctionnalité et de l'utilisation des produits, corrélée à des données quantitatives grâce à la télémétrie logicielle.
On fait bien ce que l’on pratique souvent
Les pratiques Agile et DevOps sont désormais établies comme des standards pour cette innovation rapide et incrémentale en ‘sprints’, fondée sur un développement en petites équipes multidisciplinaires et autonomes, impliquant toutes les parties prenantes, de la gestion de produits au développement logiciel, en passant par l’UX, les opérations et l’infrastructure. Elles permettent une prise en compte holistique et réactive des besoins clients réels, mais aussi des questions architecturales et opérationnelles très tôt dans le cycle de conception et de développement.
Cette approche DevOps incrémentale est logiquement associée à des architectures modulaires basées sur des micro-services faiblement couplés qui interagissent au travers d’interfaces bien définies sous forme d’APIs. L'un des avantages est de pouvoir innover localement et créer de nouvelles versions d'un micro-service en assurant un impact minimal sur les autres composants, et ainsi réduire et localiser considérablement les risques logiciels et opérationnels liés au changement.
Bien que contre-intuitif pour certains, le fait de déployer plus fréquemment de l’innovation permet d’améliorer fortement la stabilité et la qualité opérationnelles. Comment ? Chaque version déployée apporte des changements incrémentaux qui sont plus faciles à appréhender pour les équipes et ne concernent qu’un ou quelques microservices à la fois. De plus, grâce au rythme régulier d'innovation, l'environnement opérationnel change peu d'un déploiement à l'autre, minimisant et localisant ainsi les risques de dégradation ou de régression. Aussi, le déploiement très régulier de nouveaux codes permet de développer une pratique et une culture d'automatisation des déploiements, et donc de minimiser les erreurs humaines.
Un changement de culture s'opère également, car le fait de déployer plus souvent permet aux équipes de développer une "mémoire musculaire" collective de la manière de bien déployer. Elles s'entraînent chaque semaine ou chaque jour et comprennent et maîtrisent beaucoup mieux leurs environnements de production, par opposition aux équipes qui ne déploient de nouvelles versions qu’une ou deux fois par an, incluant des changements nombreux et complexes, où les risques d’avoir une régression ou une panne et de devoir effectuer un roll-back sont très élevés. On fait bien ce que l’on pratique souvent.
Développer, tester, supporter et résoudre
Ce changement de culture s’appuie aussi sur un changement des responsabilités et de nouveaux rôles. Avec une vélocité et une fréquence de changements localisés à des micro-services, les équipes DevOps étant les seules à comprendre l’évolution de leur code et leur architecture en profondeur, elles deviennent aussi responsables de la performance en production avec leurs SRE (Site Reliability Engineers), qui ont une visibilité de bout-en-bout sur le code, l’architecture, l’infrastructure et les niveaux de performance attendus (SLI/SLO/SLA). Si un problème survient, à tout moment, les SRE et les développeurs font désormais partie de la chaîne de gestion des alertes et des incidents et sont notifiés directement pour en assurer la résolution.
Ce mode DevOps, s’il est correctement mis en place, permet ainsi d'innover rapidement et de faire que tous les membres de l'équipe se sentent responsables non seulement de la fonctionnalité, mais aussi de la facilité d'utilisation, de la disponibilité, des performances et de l'expérience.
Le rapport "State of DevOps 2019" décrit comment les meilleures organisations DevOps déploient des logiciels en moyenne 208 fois plus souvent et 106 fois plus rapidement depuis le codage jusqu'à la production, mais subissent aussi 7 fois moins d'incidents pendant les déploiements et récupèrent 2600 fois plus vite après un incident. On fait bien ce qu’on pratique souvent.
Mesurer pour performer, la nécessité de la télémétrie
Afin de conjuguer haute vélocité de développement et hauts niveaux de performance opérationnelle, il convient de s'inspirer de la Formule 1 ou de SpaceX. Pour délivrer des performances hors du commun à vitesse élevée, il faut faire appel aux instruments et à la télémétrie. La technologie moderne permet d’instrumenter les architectures logicielles et les infrastructures pour collecter leur télémétrie en temps réel et l’exploiter via des plateformes d’observabilité.
La télémétrie est devenue essentielle pour gérer des systèmes complexes basés sur des architectures en micro-services hautement modulaires, avec des déploiements de versions des milliers de fois par jour, et reposant sur des infrastructures volatiles et évolutives basées sur le cloud et les containers.
Les équipes qui ont l'ambition d'innover et de faire évoluer leur secteur doivent intégrer la télémétrie et l'observabilité en temps réel dans leurs pratiques d'innovation et établir une culture axée sur les données.
Penser compétences et équipes
Accélérer l’innovation en préservant l’excellence opérationnelle est un véritable travail d’équipe et les compétences, les personnalités et la culture jouent un rôle essentiel dans cette transformation. Chaque entreprise doit identifier, selon son objectif commercial et ses impératifs de vitesse, les compromis à faire entre la formation des compétences internes, l'expérience et le savoir-faire nécessaires à leurs objectifs et savoir recruter des ressources et des savoir-faire clés à l'extérieur.
L'équipe idéale doit pouvoir, au minimum, réunir les capacités suivantes : penser en termes de service, d'expérience et de performance, et pas seulement en termes de technologie ; mettre en œuvre des approches Agile et DevOps incluant l’amélioration en continu et une culture du “blameless post-mortem” de l’analyse des incidents ; automatiser et systématiser les processus de développement, de déploiement, et de gestion de la performance et des incidents ; collaborer et coordonner la gestion des incidents et s'approprier ou attribuer la responsabilité grâce à une compréhension globale du système ; comprendre l’architecture logicielle et l’infrastructure de bout-en-bout (Full-stack) ; et enfin maîtriser l’observabilité pour une gestion de la performance basée sur les données.
Par Grégory Ouillon, CTO, EMEA à New Relic
