Modernisation d'Applications

Ingénierie de plateforme : tirez parti de l’expérience Google

Fri, 24 Oct 2025 05:00:00 +0000

Comment abordez-vous le développement logiciel ? Chez Google, nous nous efforçons constamment de créer de meilleurs services, plus rapidement. Pour y parvenir, notre équipe Developer Platform et Google Cloud ont noué un partenariat stratégique et se mobilisent autour d’une vision commune : capitaliser sur nos solutions internes et nos outils d’ingénierie pour les mettre à disposition des clients Google Cloud.

Le premier défi du développement logiciel consiste à bien comprendre comment les équipes, petites ou grandes, peuvent trouver le juste équilibre entre efficacité, qualité et coûts, tout en créant de la valeur. À l’occasion de notre récente intervention lors de PlatformCon 2025, nous avons présenté les éléments clés de notre approche de l’ingénierie de plateforme, une approche que nous avons baptisée « shift down ».

Le shift down consiste à intégrer les décisions et les responsabilités directement au sein des plateformes internes de développement (IDP), afin de réduire la charge opérationnelle qui pèse sur les développeurs. Elle se distingue de la tendance DevOps du shift left, qui vise à déplacer davantage d’efforts en amont du cycle de développement, une méthode qui montre ses limites à grande échelle face à l’ampleur et au rythme des évolutions des besoins.
Là où le shift left tend à alourdir la charge des équipes lorsqu’il est appliqué à grande échelle, le shift down cherche au contraire à tirer le maximum de valeur des ressources existantes. Cette approche permet aux entreprises d’innover rapidement tout en maintenant un niveau de qualité, de risque et de coûts soutenables, quels que soient leurs modèles économiques.

Lors de notre intervention, nous avons partagé plusieurs enseignements qui se sont révélés particulièrement utiles dans notre démarche en matière de développement logiciel et d’ingénierie de plateforme :

Partir du modèle économique. En prenant le modèle économique comme point de départ, les organisations peuvent orienter l’évolution de leur plateforme et de leurs investissements en fonction de leurs objectifs de marge, de leur tolérance au risque et de leurs exigences de qualité. Chez Google, notre plateforme centrale doit répondre à une grande diversité de modèles économiques, ce qui impose un travail constant de raffinement stratégique et d’adaptation..
Se concentrer sur les critères de qualité pour un pilotage centralisé. Les critères de qualité — fiabilité, sécurité, efficacité et performance — sont des caractéristiques transverses émergentes (ou emergent properties) des systèmes logiciels. Elles jouent un rôle essentiel pour créer de la valeur métier et maîtriser les risques. On les qualifie souvent « d’exigences non fonctionnelles » car ils décrivent la manière dont le logiciel se comporte, et non ce qu’il fait fonctionnellement. Avec une stratégie shift down, la responsabilité de ces critères de qualité peut être intégrée directement au sein des systèmes et de l’infrastructure de la plateforme, réduisant ainsi considérablement la charge opérationnelle qui pèse sur chaque développeur.
Abstractions et couplage, deux leviers essentiels pour maîtriser les critères de qualité. Notre approche de la conception de plateformes repose sur deux leviers techniques essentiels pour maîtriser les critères de qualité : les abstractions et le couplage. Dans une stratégie shift down, les abstractions permettent de rendre les systèmes plus compréhensibles, de mieux gérer les risques, de clarifier les responsabilités et de contrôler les coûts en encapsulant la complexité. Le couplage, quant à lui, indique le degré d’interconnexion et d’interdépendance entre les composants d’un système ou d’un écosystème de développement. Pour réussir une stratégie shift down, le bon niveau de couplage est déterminant, car il permet à la plateforme et à l’écosystème de développement d’intégrer et d’influencer directement les critères de qualité. Concrètement, c’est grâce au couplage que nous pouvons proposer des solutions complètes d’infrastructure et de plateforme sous forme de services cohérents, comme Google Kubernetes Engine (GKE).
Responsabilités partagées, formation et règles communes sont des leviers « sociaux » essentiels. À grande échelle, la responsabilité partagée constitue un levier organisationnel déterminant. Elle repose d’abord sur la formation, par exemple en sensibilisant les ingénieurs à l’usage des plateformes et de l’IA. Elle s’appuie aussi sur la promotion d’une culture one team (« une seule équipe ») afin d’encourager les profils centrés sur un livrable ou un composant donné à s’ouvrir à la mission globale et à l’engagement envers les clients. Par ailleurs, des règles explicites, comme des guides de style appliqués de manière centralisée ou des API conçues dès l’origine pour être sécurisées (secure by design), permettent d’intégrer des garanties de qualité directement dans la plateforme et l’infrastructure, réduisant ainsi considérablement la charge opérationnelle des développeurs tout en assurant la cohérence et l’automatisation des contrôles à grande échelle.
Utiliser une cartographie. Gérer les besoins de nombreuses entités métiers avec une seule plateforme est un problème vaste et complexe : il vous faut donc une cartographie. Chez Google, nous utilisons ce que nous appelons le modèle d’écosystème, un framework conceptuel qui fait office de cartographie et qui permet de classer les différents environnements de développement logiciel, allant de systèmes très flexibles, sous contrôle direct des développeurs, à des environnements fortement intégrés et normés, où c’est l’écosystème lui-même qui garantit les critères de qualité. Le rôle essentiel de ce framework est de fournir un outil visuel et conceptuel permettant d’évaluer dans quelle mesure les mécanismes de contrôle de l’écosystème sont alignés avec les risques métier. Autrement dit, il sert à vérifier que le niveau de supervision et de garantie des critères de qualité est proportionné au coût potentiel des erreurs. L’objectif est de rester dans la « zone d’efficacité de l’écosystème » : un équilibre où les contrôles suffisent à limiter les risques majeurs liés aux erreurs humaines, sans pour autant imposer de contraintes excessives qui ralentiraient l’innovation et démotiveraient les développeurs.

6. Segmenter le problème en identifiant les différents types de plateformes et d’écosystèmes. L’expérience développeur et l’infrastructure de la plateforme évoluent en fonction de l’échelle et du degré de shift down. Il ne suffit donc pas de savoir où se situe la « zone d’efficacité de l’écosystème » : il faut aussi identifier le type d’écosystème auquel on a affaire. Nous distinguons les écosystèmes en fonction du niveau de supervision et de garantie appliqué aux critères de qualité. Plus un écosystème devient intégré verticalement — comme l’écosystème fortement optimisé « Assured » de Google (Type 4) — plus la plateforme prend nativement en charge des critères de qualité essentiels. Cela permet aux spécialistes, tels que les site reliability engineers (SRE) ou les équipes de sécurité, d’assumer pleinement leur rôle grâce à une observabilité à grande échelle et à des capacités intégrées. À l’inverse, dans des écosystèmes moins homogènes comme « YOLO », « AdHoc » ou « Guided » (Types 0 à 2), les développeurs gèrent une part plus importante de la responsabilité en matière de qualité, tandis que les équipes spécialisées disposent de moins de leviers de contrôle direct et de mécanismes d’application moins étendus. Précisons toutefois : les modèles précités (Assured, YOLO, AdHoc et Guided) ne sont pas des indicateurs de maturité. Le meilleur type d’écosystème et de plateforme est simplement celui qui correspond le mieux aux besoins de votre entreprise (cf. point n°1 ci-dessus !).

Faire les bons choix en matière d’ingénierie de plateforme

En résumé, la leçon la plus importante à retenir, c’est qu’il faut bien peser ses choix et prendre des décisions éclairées. L’ingénierie de plateforme doit être adaptée à chaque entité métier et à chaque application afin d’obtenir les meilleurs résultats. Elle doit avant tout s’attacher à repérer les problèmes récurrents, qui reviennent systématiquement dans différents domaines métier, pour les résoudre une bonne fois pour toutes avec des solutions robustes et réutilisables. Cette approche est au cœur de notre stratégie de shift down. Elle vise à aller vers des plateformes composables, capables d’intégrer directement dans l’infrastructure les décisions et les responsabilités liées à la qualité logicielle. Concrètement, cela signifie que la plateforme prend en charge directement les choix et les responsabilités liés à la qualité logicielle (sécurité, fiabilité, performance, etc.), au lieu de les laisser reposer uniquement sur les développeurs. Dit autrement, avec l’approche shift down, vous renforcez votre capacité à maximiser la valeur métier en mobilisant les bonnes ressources, au niveau de qualité requis, et avec des coûts maîtrisés dans la durée.

Pour aller plus loin, n’hésitez pas à consulter l’intégralité de notre intervention à PlatformCon 2025 sur le sujet.

Ingénierie de plateforme : une nouvelle étude révèle les clés du succès

Fri, 21 Mar 2025 07:00:00 +0000

Selon Gartner, l'ingénierie de plateforme compte parmi les 10 tendances technologiques stratégiques du moment. Elle s’est rapidement imposée comme un atout incontournable pour accélérer le développement logiciel et booster la productivité des équipes de développement. De fait, l’ingénierie de plateforme crée un écosystème optimal avec l’infrastructure, les outils et les processus adaptés pour accélérer le développement, simplifier le déploiement et assurer une gestion fluide des logiciels, tout en allégeant la charge mentale des développeurs.

Pour percer les secrets d'une ingénierie de plateforme réussie, Google Cloud s'est associé à Enterprise Strategy Group (ESG) pour mener une étude approfondie auprès de 500 professionnels de l'IT et développeurs d'applications. Cette enquête a ciblé des organisations de plus de 500 employés disposant déjà d'équipes dédiées à l'ingénierie des plateformes. Notre objectif : savoir si elles avaient déjà adopté l'ingénierie de plateforme et, dans l’affirmative, analyser les retombées sur leur cycle de développement logiciel.

Le rapport, baptisé « Building Competitive Edge With Platform Engineering: A Strategic Guide » (Transformer l’Ingénierie de plateforme en avantage concurrentiel : le guide stratégique), met en lumière les schémas récurrents, les attentes des équipes et les bonnes pratiques à mettre en œuvre pour surmonter les obstacles et exploiter pleinement le potentiel de l'ingénierie de plateforme. Nous vous proposons, à travers cet article, d’en découvrir les enseignements les plus marquants.

L'ingénierie de plateforme s'impose comme impératif stratégique

L'étude confirme que l'ingénierie de plateforme a dépassé le stade de concept émergent. En effet, 55 % des organisations internationales sollicitées l'ont déjà adoptée, et parmi elles, 90 % prévoient d'en étendre l'utilisation à davantage de développeurs. Plus révélateur encore, 85 % des entreprises qui l'ont mise en place indiquent que leurs développeurs comptent dessus pour réussir. Ces chiffres montrent clairement que l'ingénierie de plateforme n'est plus une simple tendance : elle s'impose comme une stratégie essentielle pour les organisations qui souhaitent maximiser le rendement de leurs investissements cloud et IT, et ainsi gagner en avantage concurrentiel.

Figure 1 : Plus de la moitié (55 %) des 900+ organisations mondiales sondées ont déjà franchi le pas vers l’ingénierie de plateforme.

Trois clés incontournables pour réussir

Le rapport identifie trois pratiques déterminantes qui caractérisent les organisations les plus matures en ingénierie de plateforme :

Une collaboration étroite entre les ingénieurs plateforme et les autres équipes afin de garantir l'alignement des objectifs.
Une plateforme utilisée comme un véritable produit, ce qui implique de gérer la plateforme de développement avec une feuille de route claire, une proposition de valeur explicite et des boucles de rétroaction (feedback) courtes.
Des indicateurs précis pour mesurer la performance, tels que la fréquence des déploiements, le temps de résolution des incidents ou le délai de mise en œuvre des changements.

Un constat s'impose néanmoins : malgré l'engouement croissant pour l'ingénierie de plateforme, seulement 27 % des organisations ont réussi, jusqu'ici, à mettre pleinement en œuvre ces trois composantes essentielles. Dit autrement, la marge d’amélioration de la majorité des organisations est considérable.

L'IA : nouvelle alliée de l'ingénierie de plateforme

Un constat majeur se dégage de cette étude : la convergence naturelle entre l'ingénierie de plateforme et l'IA. Les chiffres parlent d'eux-mêmes : 86 % des participants estiment que l'ingénierie de plateforme est indispensable pour exploiter pleinement la valeur business de l'IA.
En parallèle, une large majorité des entreprises voit dans l'IA un accélérateur du développement de l'ingénierie de plateforme, 94 % d'entre elles la jugeant « Critique » ou « Importante » pour son évolution.

Figure 2 : L’IA et le ML façonnent l’avenir de l’ingénierie de plateforme, 94 % des organisations les jugeant "cruciaux" ou "importants".

Au-delà de la vitesse : les avantages clés de l'ingénierie de plateforme

En se basant sur le niveau d'intégration des pratiques clés mentionnées précédemment, l'étude a classé les organisations dans trois catégories : émergentes, établies et leaders. Les résultats montrent que les organisations leaders obtiennent de meilleurs résultats en termes de rapidité, efficacité et productivité.
Forte de ces enseignements, l’étude propose des pistes d'amélioration aux organisations naissantes comme bien établies pour accroître leur maturité et maximiser leurs bénéfices.

Mais elle met également en lumière deux autres avantages significatifs :

L’amélioration de la satisfaction des employés, de l’acquisition de nouveaux talents et de la fidélisation des collaborateurs : les plateformes matures favorisent une expérience développeur positive qui influence directement la culture d'entreprise. Les développeurs et professionnels de l'IT qui travaillent dans des organisations disposant de plateformes matures sont nettement plus enclins à recommander leur entreprise à leurs pairs.
L’accélération du Time-to-market : les organisations les plus matures en ingénierie de plateforme ont considérablement raccourci leurs cycles de développement. 71 % des « leaders » indiquent avoir significativement accéléré la livraison de services, contre seulement 28 % des organisations moins matures.

Exit la stratégie solo

Une large majorité (96 %) des organisations interrogées s'appuient sur des outils open source pour construire leurs plateformes. Autre fait notable, la plupart d'entre elles (84 %) collaborent avec des prestataires externes pour gérer et maintenir leurs environnements open source.

Cette approche collaborative, impliquant un partenaire tiers ou fournisseur de cloud, favorise l'innovation. En effet, les organisations ayant adopté ce modèle de cogestion constatent que leurs développeurs consacrent en moyenne 47 % de leur temps productif à l'innovation et à l'expérimentation, contre 38 % pour celles qui gèrent leurs plateformes en interne.

Prêts à passer à la vitesse supérieure ? Découvrez l'étude complète

Nous n’avons présenté ici qu'un aperçu des enseignements de l'étude. N’hésitez pas à consulter notre rapport complet afin de découvrir l'ensemble des stratégies et pratiques pour exceller en ingénierie de plateforme et garder une longueur d'avance. Vous pourrez notamment approfondir certains points, tels que :

Les enjeux stratégiques autour des équipes d'ingénierie des plateformes centralisées et distribuées ;
Les principaux moteurs d’investissements en ingénierie des plateformes ;
Les priorités majeures des développeurs dans l'adoption des plateformes, pour garantir l'alignement avec leurs besoins ;
Les points critiques à anticiper pour réussir votre transition vers l'ingénierie de plateforme ;
Comment l'ingénierie de plateforme stimule la productivité, la performance et l'innovation dans toute l'organisation ;
L'importance stratégique de l'open source dans l'ingénierie de plateforme pour obtenir un avantage concurrentiel ;
Le rôle transformateur de l'ingénierie de plateforme pour les workloads IA/ML face à l'adoption croissante de l'IA ;
Comment élaborer une stratégie d'ingénierie de plateforme adaptée pour favoriser l'évolutivité et l'innovation.

Téléchargez le rapport complet dès maintenant.

Pour vos besoins de modernisation, oubliez le "Shift Left" ! Visez le "Shift Down" !

Tue, 04 Mar 2025 08:00:00 +0000

Bienvenue sur notre toute première publication de « The Modernization Imperative », également connu sous le nom de "TMI", un acronyme qui capture parfaitement notre mission : partager avec enthousiasme tout ce qui concerne la Tech.

Cette chronique portée par les leaders de Google Cloud veut, au fil des épisodes, explorer l'univers du développement logiciel, des systèmes distribués, du serverless, des microservices, du DevOps & SRE, des opérations de plateforme... bref, tous les buzz words qui font vibrer nos experts !

Aujourd'hui, c'est Richard Seroter qui prend la plume. Directeur de la Stratégie et de l'Engagement pour l'équipe Infrastructure Moderne de Google Cloud, il cogite sur ces sujets depuis près de 20 ans.

Alors, chers lecteurs, accrochez-vous : après tout, quand on parle d'infrastructure moderne, il n’y a jamais trop d'infos !

Seul au volant d'une voiture glaciale, le petit Richard alors âgé de 10 ans se prenait pour un roi. « Vroom, vroom… Regarde-moi, je conduis ! » lançais-je fièrement à mon passager imaginaire. Ce n'est que des années plus tard que j'ai compris le stratagème de ma mère. Elle me "laissait" démarrer notre voiture. J'étais tellement ébloui par mes talents de pilote hors pair que je ne réalisais pas que je faisais une tâche dont elle voulait se débarrasser : faire chauffer le moteur et monter la température interne du véhicule avant notre trajet matinal.

Aujourd'hui ? Rien n'a vraiment changé, sauf ma lucidité. À quarante et quelques années, me voilà en train de marteler frénétiquement l'écran tactile d'une caisse automatique, cherchant désespérément le code des « raisins sans pépins » tout en savourant le « privilège » de scanner moi-même et d'emballer mes propres courses.

De ma mère à mon supermarché local en passant par le développement logiciel, redistribuer les tâches d'un groupe à un autre est une étape cruciale pour optimiser les ressources. Aujourd'hui, nous demandons à nos développeurs de pratiquer du "Shift Left" et de s'adapter à des méthodologies en constante évolution.

Mais c'est un fardeau lourd à porter. Plutôt que de surcharger nos développeurs, pourquoi ne pas maximiser leurs talents en exploitant pleinement l'éventail des outils et services à leur disposition ?

Certes, le « Shift Left » - cette pratique qui consiste à intégrer les contrôles de sécurité et de qualité plus tôt dans le processus de développement - est une idée tout à fait sensée. Mais au fil des ans, de plus en plus de tâches, traditionnellement hors du périmètre des développeurs, ont « glissé vers la gauche » au nom de la sacro-sainte polyvalence et autonomisation des « ingénieurs full stack ». Il est temps que cela cesse.

[Mini coup de gueule, mais justifié : Il y a genre neuf vrais « ingénieurs full stack » sur Terre. Pratiquement personne ne code un frontend en React, ne configure Kubernetes, ne paramètre une instance RabbitMQ, ne provisionne de l'espace sur un SAN et n'allume un switch top-of-rack, tout ça dans une même journée. Aujourd'hui, on demande aux développeurs de maîtriser les frameworks web, les patterns d'architecture, les stratégies de test, les systèmes de build, de multiples types de bases de données, les caches, les outils d'automatisation, les orchestrateurs de conteneurs, les concepts réseau L4-L7, les API SaaS, les systèmes de monitoring, de nombreux clouds publics, et oh, pourquoi pas un peu de machine learning ! Je viens de parcourir Indeed.com, et c'est hallucinant de voir ce qu'on exige des développeurs juniors et seniors. C'est trop, tout simplement.]

En tant qu’industrie, nous ne pouvons rester immobiles et ne pas intervenir.

Shift Down !

Dans un premier temps, au lieu de dire aux développeurs (et à leurs managers !) de tout « décaler à gauche » (un Shift Left), nous devrions les encourager à « descendre d'un cran » (un Shift Down) et tirer pleinement parti des technologies disponibles en refilant le boulot aux plateformes qu'ils utilisent déjà.

Simplifiez votre pile technologique. N'obligez pas les gens à tout connaître pour faire leur job. Offrez des abstractions de plateforme. J'ai récemment fait une présentation pour un client sur « comment Google pratique le DevOps », mettant ainsi en lumière le nombre conséquent de plateformes que nous offrons à nos ingénieurs. Nous proposons des solutions managées pour le codage, les tests, la compilation, les déploiements, l'hébergement, les alertes et bien plus encore. Des équipes dédiées chez Google soutiennent ces plateformes essentielles afin que nos ingénieurs produits puissent se concentrer sur leur travail sans avoir à connaître ou gérer une "pile complète" d'infrastructure. Et, chaque organisation devrait en faire autant.

Au lieu d'exiger toujours plus de leurs équipes d'ingénierie actuelles - en leur demandant d'apprendre de nouveaux langages, plateformes et clouds - les dirigeants technologiques devraient désormais chercher à assembler des équipes d'ingénierie de plateforme qui traitent leurs diverses plateformes comme des produits à part entière.

L’optimisation commence par la réduction de la charge cognitive des développeurs et l’élimination des tâches inutiles qui les détournent de l’innovation. En parallèle, il est essentiel de leur fournir les outils et l’infrastructure nécessaires pour exploiter la puissance de l’IA et des modèles de langage (LLM). Ainsi, vos développeurs pourront se concentrer sur la création plutôt que sur des tâches répétitives. Nous mettons actuellement en place davantage de coaching et de supports pour aider chacun à adopter l'ingénierie de plateforme, alors restez à l'écoute !

Tout un potentiel à portée de mains

Dans un second temps, en tant que fournisseurs de cloud, nous pouvons accompagner les développeurs avec des principes universels de "déchargement", de « Shift down », qui assurent un partage de la charge de gestion de l'infrastructure.

J'apprécie, par exemple, que GKE Autopilot me fournisse à la demande un cluster Kubernetes sécurisé et managé, sans perturber mon flux de travail. Si vous devez utiliser Kubernetes, adoptez la méthode Autopilot et dites adieu aux prises de tête liées au provisionnement d'un cluster qui vous détourne du développement.

Autre exemple, vous voulez une chaîne d'approvisionnement sécurisée ? Ne demandez pas à un humain de décoder les manifestes Supply Chain Levels for Software Architects (SLSA). Ajoutez automatiquement des attestations aux builds (comme nous le faisons avec Cloud Build) et transformez les vérifications d’exécution… en une simple case à cocher !

Parallèlement, rendez les services hautement disponibles par défaut au lieu de demander à un développeur de se débrouiller. Nos services comme Pub/Sub, Firestore, Spanner, Cloud Storage ou Cloud Logging fonctionnent "tout simplement" et nativement de cette façon.

Nous pouvons également intervenir à un niveau plus bas, en aidant quelqu’un à analyser CloudEvents dans son code au lieu de le laisser se débrouiller seul.

Enfin, avec des outils comme Generative AI App Builder, les développeurs peuvent rapidement proposer de nouvelles expériences captivantes, telles que des assistants digitaux, des moteurs de recherche personnalisés, des interfaces de chat, et bien plus encore. Offrir aux clients des frameworks structurés mais extensibles, qui maximisent leur investissement technologique, est la clé d'une expérience cloud réussie.

Chez Google Cloud, nous aidons les entreprises à utiliser des technologies incroyables pour réaliser des choses extraordinaires. Pour y parvenir, nous créons des outils et des services qui offrent aux développeurs une expérience matérielle et logicielle sécurisée par conception (secure by design). Cela leur permet d'appliquer de façon totalement automatisée nombre de bonnes pratiques de "Shift Left", accélérant ainsi le développement. En assignant efficacement les workloads, nous veillons à ce que les ressources d'ingénierie restent disponibles et performantes au maximum de leur capacité, au moment où vous en avez le plus besoin.

Être développeur en 2024 est une expérience extraordinaire. Mais le job s’accompagne d’une charge mentale parmi les plus lourdes, toutes professions confondues. Plutôt que de surcharger les équipes de devs avec toujours plus de responsabilités dans le cycle de vie du logiciel, chez Google Cloud nous aidons nos clients à mettre en place une approche « plateforme » qui favorise une culture d’ingénierie durable et innovante. En adoptant les pratiques de « Shift Down » et en exploitant pleinement les avantages d'une stack technologique complète, l'innovation s’épanouit grâce à des automatisations bien ficelées et des services managés.

Nous sommes aujoud’hui à l'aube d'une nouvelle ère de technologies dopées par l'IA, où la création de code se simplifie et où les devs se tournent vers des chatbots en langage naturel pour obtenir des conseils en temps réel. Il est temps d’offrir aux développeurs du monde entier les moyens de favoriser le succès technologique et commercial. Et, contrairement au jeune Richard d’une dizaine d’années, leur permettre vraiment d’aller quelque part…

Briser les silos, libérer le potentiel : la boucle de rétroaction, l'élément clé d'une modernisation “agile”

Wed, 04 Sep 2024 08:00:00 +0000

Dans un monde où la rapidité, l'efficacité et l'innovation sont les maîtres mots, les entreprises font face à des défis de taille. Développement accéléré de produits, maîtrise des coûts, gestion optimale des incidents, bien-être des équipes... Les enjeux sont multiples et complexes.

Pour répondre à ces impératifs, de nombreuses organisations se sont tournées vers les méthodes dites "agiles", promettant flexibilité, collaboration et amélioration continue. Pourtant, force est de constater que l'adoption de ces frameworks n'a pas toujours été couronnée de succès. Désillusion, frustration, retour aux anciennes pratiques... Le constat est parfois amer : "Agile" ne tiendrait pas ses promesses.

Mais si l'échec n'était pas dû à l'approche elle-même, mais plutôt à une mise en œuvre incomplète ? Car un élément essentiel manque souvent dans ces transformations : la boucle de rétroaction (feedback loop). Véritable moteur de l'amélioration continue, elle permet de tirer les leçons du passé, d'ajuster le présent et de préparer l'avenir.

Alors, comment intégrer efficacement la boucle de rétroaction dans votre organisation ? Comment briser les silos et libérer le potentiel de vos équipes ? C'est ce que nous allons explorer ensemble dans cet article. Préparez-vous à découvrir comment cet outil simple, mais puissant, peut transformer votre façon de travailler et vous propulser vers une modernisation réussie.

La boucle de rétroaction : un thermostat pour votre organisation

"On ne peut pas améliorer ce qu'on ne mesure pas", disait Peter Drucker, le père du management moderne. Cette citation résume parfaitement l'essence de la boucle de rétroaction. Elle vous permet justement de mesurer, d'analyser et d'agir pour progresser en continu. Imaginez un thermostat : il mesure la température ambiante, la compare à la valeur souhaitée, puis déclenche le chauffage ou la climatisation pour corriger l'écart. De la même manière, la boucle de rétroaction vous permet de "mesurer la température" de votre organisation, d'identifier les écarts par rapport à vos objectifs, et de mettre en place les actions nécessaires pour atteindre vos cibles.

Comme nous le verrons dans les paragraphes suivants, certains composants de votre organisation peuvent entraver la mise en place d’une boucle de rétroaction efficace. Mais avant cela, revenons sur les bénéfices qu’apporte cette pratique.

Les bénéfices de la boucle de rétroaction : flexibilité, résilience et performance

Imaginez une organisation capable de s'adapter rapidement aux évolutions du marché, de rebondir après un échec, d'innover en permanence et de motiver ses équipes. Cette organisation existe, et son secret réside dans la mise en place d'une boucle de rétroaction efficace. En maîtrisant ces différents types de feedback, vous pourrez créer une culture de l'amélioration continue au sein de votre organisation, où chaque voix est entendue et chaque contribution valorisée.

La boucle de rétroaction n'est pas réservée à un domaine spécifique. Elle peut être appliquée à tous les niveaux de votre organisation :

Au niveau stratégique : pour évaluer la pertinence de vos orientations et ajuster votre cap en fonction des évolutions du marché.
Au niveau opérationnel : pour améliorer la performance de vos processus et la qualité de vos produits/services.
Au niveau individuel : pour favoriser le développement des compétences et la progression de carrière de vos collaborateurs.
Au niveau global : pour aider à la maîtrise des coûts et à la responsabilisation des équipes.

Mettre en place la boucle de rétroaction : un entraînement progressif

Mais comment mettre en place une telle boucle de rétroaction ? La clé est de commencer petit, d'expérimenter et d'apprendre. Vous pouvez par exemple choisir un processus spécifique, une équipe pilote ou un projet limité dans le temps pour tester la mise en place d'une boucle de rétroaction. Cette approche "agile" vous permettra de valider rapidement les bénéfices de la démarche et d'identifier les ajustements nécessaires.

Une fois les premiers résultats positifs obtenus, vous pourrez étendre progressivement la pratique à d'autres équipes, d'autres processus et d'autres niveaux de l'organisation. L'objectif est de créer une culture du feedback, où l'échange d'informations, l'analyse des résultats et l'amélioration continue deviennent des réflexes naturels. N'oubliez pas : la mise en place d'une boucle de rétroaction efficace prend du temps et demande de l'engagement de la part de tous les acteurs de l'organisation. Mais les bénéfices sont à la hauteur de l'investissement : une organisation plus agile, plus résiliente et plus performante.

Les défis de la mise en place d'une boucle de rétroaction efficace

Si la boucle de rétroaction est un outil puissant pour l'amélioration continue, son intégration au sein d'une entreprise peut se heurter à des obstacles structurels et culturels. Pour bien comprendre les mécanismes en jeu, il s’agit tout d’abord de considérer les différents types de feedback:

Feedback positif : Il souligne les réussites, les points forts et les bonnes pratiques, renforçant ainsi les comportements positifs et encourageant à poursuivre dans la même direction.
Feedback négatif : Il met en évidence les erreurs, les dysfonctionnements et les axes d'amélioration, permettant d'identifier les problèmes et de mettre en place des actions correctives.
Feedback équilibré : Il combine les deux précédents, en soulignant à la fois les points positifs et les points à améliorer, permettant ainsi de progresser tout en maintenant la motivation et l'engagement.

Comme expliqué par Ron Westrum, la culture organisationnelle joue un rôle déterminant dans la réussite de la mise en place d’une boucle de rétroaction. Les organisations dites “génératives” favorisent la remontée de tous les types de feedback. Dans ce type d’organisation, les feedbacks négatifs sont d’ailleurs analysés en priorité afin de prendre les prochaines actions d’amélioration. De même, en donnant la parole aux collaborateurs et en valorisant leurs retours, ces organisations contribuent à créer un climat de confiance et d’ouverture.

A l’inverse, des organisations “pathologiques” ou “bureaucratiques”, caractérisées par une hiérarchie rigide et une communication descendante, sont moins propices à l'échange d'informations et à l'apprentissage. La "peur du jugement" inhibe par défaut le feedback négatif, essentiel pour identifier les axes d'amélioration et les problèmes à résoudre. Ces organisations restent donc généralement dans des modes “réactifs” plutôt que “proactifs” pour tout ce qui relève de la gestion d’incident.

La culture organisationnelle et la boucle de rétroaction s'influencent mutuellement : une culture ouverte favorise la mise en place de boucles de rétroaction efficaces, et ces dernières contribuent à transformer la culture en profondeur.

Conclusion : la boucle de rétroaction, un investissement rentable

N'hésitez plus à vous lancer dans l'aventure de la boucle de rétroaction ! Commencez par un projet pilote, impliquez vos équipes et soyez ouverts aux retours, qu'ils soient positifs ou négatifs. Vous découvrirez rapidement les bénéfices de cette démarche et vous serez sur la voie d'une organisation plus agile, plus résiliente et plus performante. N'oubliez pas que la mise en place d'une boucle de rétroaction efficace demande du temps, de la persévérance et une transformation de la culture d'entreprise. Mais les bénéfices à long terme en valent largement la peine : une organisation plus performante, plus innovante et plus résiliente face aux défis de demain.

5 façons pour les ingénieurs de plateforme d’aider les développeurs à créer des API performantes

Thu, 13 Jun 2024 09:00:00 +0000

Pour concevoir des applications modernes, il faut des développeurs capables de créer des API en un temps record qui offrent à la fois des fonctionnalités complexes et de très hautes performances. Il faut aussi des ingénieurs de plateforme (platform engineers). Véritables piliers des architectures modernes, héros discrets mais pourtant essentiels des applications modernes, ils fournissent aux développeurs les bons outils et les bonnes pratiques pour leur simplifier la tâche.

En tant qu’ingénieur de plateforme, vous pouvez influencer la conception des API en adoptant cinq stratégies fondamentales. Plus concrètement, vous pouvez aider vos développeurs :

En traitant les API et les plateformes internes comme des « produits »
En intégrant la gestion des API dans votre plateforme interne
En construisant des pipelines CI/CD pour vos proxies et vos politiques
En simplifiant la consommation des API par vos développeurs en leur proposant une « voie royale »
En tirant parti d'Apigee pour la gestion et l'automatisation des API

1. Traiter les API et les plateformes internes comme des produits

Aujourd’hui, toute expérience numérique connectée de qualité repose sur des API, autrement dit des mécanismes qui permettent aux applications de communiquer entre elles. En termes simples, les API sont des solutions logicielles pour intégrer des services. Comme toute autre solution logicielle, les API doivent être testées, sécurisées, déployées et gérées en s’appuyant sur des process systématiques, tels que le cycle de vie du développement logiciel (ou SDLC pour Software Development Life Cycle). Des plateformes internes permettent de mettre en place de véritables processus de livraison des API. Elles fournissent aux développeurs un ensemble d’outils communs et des modèles clairement définis. Par exemple, si votre organisation a décidé que toutes les applications doivent accéder aux API en présentant un jeton OAuth, l’ingénieur plateforme peut tout à fait simplifier et fluidifier le travail du développeur en mettant à sa disposition un pipeline de flux partagé, utilisé pour associer une politique OAuth v2 au proxy à l'aide d'une règle FlowCallout.

Tout comme les API, les plateformes internes sont des solutions logicielles. L’une des principales missions de toute équipe d’ingénierie plateforme qui se respecte est de briser les silos internes afin de pouvoir travailler harmonieusement avec les autres équipes de l’entreprise et mieux comprendre les besoins de chacun. Fondamentale, cette collaboration permet au final aux développeurs de disposer de meilleurs outils.

2. Intégrer la gestion des API dans votre plateforme interne

En tant qu’ingénieur plateforme, votre première mission consiste à créer des plateformes en interne que vos développeurs peuvent utiliser. Ces plateformes favorisent l’autonomie des développeurs en leur donnant directement accès à des modèles et des outils validés et standardisés par votre organisation. En créant de tels outils et modèles et en les intégrant à votre plateforme, vous assurez une bonne gestion et prise en compte de tous les aspects clés d’une API, à commencer par la normalisation, la sécurité, les quotas, la surveillance ou encore le déploiement automatisé.

3. Construire des pipelines CI/CD pour vos proxies et vos politiques

Les API étant des solutions logicielles, elles doivent être créées et gérées avec du code. Une des tâches courantes de l’ingénieur plateforme est de créer des pipelines CI/CD afin d'automatiser le cycle de vie du développement des API. Un pipeline CI/CD standard est composé de plusieurs étapes : analyse statique du code, tests unitaires, déploiement, et tests d’intégration.

De manière générale, un développeur code localement un proxy et utilise Git pour transférer le code de ce proxy vers un dépôt de code source. Un commit déclenche alors un pipeline automatisé qui effectue des tests et fournit des retours. Si cela réussit, le code est transféré dans différents environnements jusqu'à sa mise en production.

Après avoir construit vos API, vous souhaitez naturellement qu'elles soient découvrables par d'autres dans votre organisation. L’« API Hub » d’Apigee est idéale pour la découverte interne des API.

Parallèlement, un « portail des développeurs » peut automatiquement être généré avec la documentation de vos API pour offrir aux développeurs externes (ceux de vos clients) un moyen de les découvrir, d’apprendre à les utiliser, d’en réclamer l’accès, de les essayer, etc.

4. Simplifier la consommation des API par vos développeurs en leur proposant une « voie royale »

Le principe de la « voie royale » est assez simple : l’objectif est de proposer des modèles qui intègrent le code et l’outillage afin d’accélérer au maximum les temps de développement. Vous aidez ainsi le développeur à construire rapidement son chemin vers la livraison logicielle – d’où cette notion de voie royale – en lui proposant des workflows et des modèles accessibles en libre-service. Ces modèles englobent des tâches courantes et des stratégies prédéfinies. Si vous développez des API avec Apigee, cette voie royale peut comprendre les éléments suivants :

Un guide pour bien démarrer
Un modèle pour construire le proxy / des stratégies prédéfinies / une simulation de backend
Des configurations pour des flux partagés standards directement exploitables
Un pipeline CI/CD pour les tests et le déploiement
Des modèles pour l’ « API Registry » (qui regroupe des descriptions standardisées, lisibles par des machines et programmes, des différentes API).

5. Tirer parti d'Apigee pour la gestion et l'automatisation des API

Un mot sur la pièce maîtresse de votre stratégie : Apigee. Plateforme de gestion des API, Apigee propose aux ingénieurs de plateforme une solution pour construire, administrer et sécuriser les API. Apigee peut être utilisé pour gérer vos API tout au long de leur cycle de vie. Dans Apigee, tout commence par un proxy, autrement dit une interface numérique située entre le client et la logique métier (ou backend). Le proxy sert également de point d'attache pour les politiques d'API (les règles et comportements associés à une API) afin de programmer et personnaliser le comportement de l'API.
Les proxys permettent également de découpler l’API en évitant un accès direct au backend et en masquent la complexité. En tant qu'ingénieur de plateforme, vous aidez les développeurs à créer de meilleures API en leur permettant de se concentrer sur la création de proxys. Votre plateforme doit dès lors être préalablement paramétrée afin d’arrêter une stratégie de fonctionnement des API.

Certains outils d’Apigee, tels que Shared Flows, vous permettent de normaliser et préserver la cohérence de vos politiques. Les politiques FlowCallout et les flow hooks permettent d'attacher ces politiques aux proxys et de les réutiliser dans les différentes API créées.

6. Concevoir de meilleures API

En traitant les API et les plateformes internes comme des « produits », en intégrant la gestion des API à votre plateforme, en exploitant Apigee pour la gestion et l'automatisation des API, en construisant des pipelines CI/CD pour vos proxies et vos politiques, et en créant des voies royales pour faciliter la consommation des API, vous aidez indubitablement vos développeurs à créer de meilleures API avec Apigee.
Si vous souhaitez obtenir plus de conseils sur le sujet et aider davantage vos développeurs, consultez ce livre blanc qui détaille la démarche. Si vous n’utilisez pas encore Apigee, n’hésitez pas à consulter notre documentation pour en savoir plus ou rendez-vous directement sur ce lien pour tester notre plateforme d’API Management.

Le succès par la culture d’entreprise : pourquoi l'acceptation de l'échec favorise une meilleure livraison logicielle

Wed, 13 Mar 2024 07:00:00 +0000

Les choses se cassent. C'est la vie. Et lorsque tout ne se déroule pas comme prévu, c'est ce qui se passe ensuite qui est vraiment important.

Des études internes réalisées par Google et par notre organisation DORA (‘DevOps Research and Assessment’) montrent que les équipes qui réussissent le mieux sont celles qui encouragent une « culture de la confiance », autrement dit un climat de travail qui autorise la remise en question, la prise de risques et les erreurs.

La culture d’une entreprise façonne notamment la façon de réagir aux opportunités qui se présentent. Mais, dans le domaine de la livraison logicielle, et plus globalement de la performance des équipes, la façon de réagir à l’échec est tout aussi importante.

En adoptant des comportements et des méthodes de travail spécifiques qui encouragent la résilience, une organisation peut accroître significativement l'efficacité de ses équipes et améliorer ses performances.

Comment identifier les leviers pour optimiser l'efficacité des équipes logicielles et des cultures organisationnelles ?

Chez Google, nous ne nous contentons pas de fabriquer beaucoup de technologies, nous nous intéressons aussi à la manière dont elles sont fabriquées.

DORA est un programme de recherche rigoureux sur le plan académique et statistique qui vise à répondre aux questions suivantes : « Comment la technologie aide-t-elle les organisations à réussir et comment pouvons-nous améliorer la livraison et l'exploitation des logiciels ? »

Grâce à des études internes portant sur des centaines d'équipes Google, tels que le projet Aristote, nous avons étudié les moteurs des équipes les plus efficaces.

Nous vous proposons ici d’entamer une nouvelle série d’articles s’appuyant sur ces années de recherches menées par Google. Nous avons regroupé les résultats selon cinq grands axes d’analyse sur lesquels (chacun formant un article) vous pouvez vous appuyer pour optimiser la réussite au sein de votre organisation :

La Résilience (le sujet de ce premier article)
La Communication
La Collaboration
L’Innovation
La Responsabilisation

La résilience… Qu’est-ce donc ? Et surtout comment peut-elle améliorer les performances ? Comment votre équipe peut-elle en tirer le meilleur profit.

Résilience : positiver l’échec, oui, mais encore…

Dans le cadre de cet article, lorsque nous parlons de résilience, nous faisons référence à la résilience culturelle. Dans ce contexte, nous définissons la résilience comme la capacité des équipes à prendre des risques mesurés, à partager ouvertement les échecs et à s'améliorer continuellement sur la base du retour d'information. Les équipes qui font preuve de résilience sont manifestement plus performantes que les autres.

L'idée qu'une culture présentant des caractéristiques de résilience peut être bénéfique à l’entreprise n’est pas nouvelle. L'étude du sociologue Ron Westrum autour de l'influence de la culture sur le comportement de l'équipe en cas d'échec a mis en évidence trois cultures organisationnelles distinctes : pathologiques, bureaucratiques, génératives. Et les cultures dans lesquelles l'échec conduit à une investigation positive, plutôt qu'à la justice ou à la désignation d'un bouc émissaire, se montrent plus orientées vers la performance. Westrum qualifie ces cultures de « génératives ».

Cette analyse du sociologue a été corroborée par nos propres résultats DORA, dès la publication du premier rapport sur l'état de DevOps en 2014. Notre rapport 2023 Accelerate State of DevOps démontre que la présence d'une culture générative continue à favoriser une meilleure livraison logicielle et une meilleure performance organisationnelle. Nous pensons que c'est parce que, à la base, DevOps est une approche qui se focalise fondamentalement sur les personnes et les méthodes de travail de ces personnes. Or, les personnes sont le moteur de la culture.

« La culture joue un rôle essentiel dans la capacité à innover et à créer des technologies… les performances des équipes ayant une culture générative sont 30% supérieures à celles qui n’en ont pas ».

Source: DORA 2023 Accelerate State of DevOps Report

Prenons, par exemple, les pratiques de développement dans le domaine de la sécurité. Nos recherches ont montré que les organisations fondées sur une culture de confiance et de résilience sont 1,6 fois plus susceptibles d'adopter des pratiques de sécurité émergentes.
Nous sommes convaincus que ces cultures génératives, résilience comprise, constituent un avantage en termes de posture de sécurité en raison de leur influence sur les méthodes de travail des équipes. Typiquement, dans les organisations « génératives », les personnes sont plus enclines à signaler un problème ou un risque de sécurité car elles ne craignent pas d’être sanctionnées sur leur « irréprochabilité ». Dit autrement, si vous voulez améliorer la posture de sécurité de votre organisation (et aller au-delà), commencez par évaluer la culture de vos équipes.

La résilience peut être redécomposée en deux états d’esprit :

Le « Démarrer puis itérer »: lancer un projet, recueillir les retours et s’améliorer en continu
La « Sécurité psychologique » : insuffler la conviction au sein de l’équipe que chaque membre peut prendre des risques en toute sécurité

Démarrer et itérer : le « parfait » est l'ennemi du bien

Êtes-vous prêt à prendre le risque de partager une idée seulement ébauchée à 20% avec vos dirigeants ?

Le concept de « résilience » repose en partie sur la collecte d’information et l’amélioration continue. Nos études montrent que les équipes fondées sur l’amélioration continue réussissent mieux. Ce qui suppose des équipes capables de démarrer rapidement, de s'adapter à des circonstances changeantes et d'expérimenter.

Par exemple, dans le cadre de la livraison logicielle, la recherche DORA soutient la philosophie d’une livraison continue afin que le logiciel soit toujours dans un état « déployable ». Pour conserver le logiciel dans un tel état, il est essentiel de mettre en place des mécanismes de collecte des feedbacks et d’être en mesure de surmonter rapidement les échecs. D’après nos études, les équipes qui donnent la priorité à ces mécanismes de feedback affichent de meilleures performances sur la livraison logicielle. Nos études montrent également qu’une livraison par petits lots (donc par fréquentes itérations) améliore la façon dont les équipes reçoivent et utilisent ce feedback, ainsi que leur capacité à se remettre d’un échec notamment.

Ce concept – démarrer et itérer – n’impacte pas uniquement la qualité du logiciel livré. De fait, il soulève aussi la question de la capacité d’une équipe à s’auto-évaluer, à s’adapter et à changer de méthode quand les résultats le justifient. Inévitablement, cette approche par l’expérimentation entraînera des succès, mais aussi des échecs. Dans tous les cas, les équipes peuvent en tirer des enseignements précieux.

Sécurité psychologique : valoriser l’échec comme un succès

Êtes-vous prêts à accepter l’idée d’échouer ouvertement devant votre équipe ?

Des recherches approfondies menées chez Google ont montré que la sécurité psychologique constitue un facteur clef pour parvenir à des équipes hautement efficaces. Dans ce cadre, nos études montrent que l’efficacité dépend moins des membres de l’équipe que de la façon dont ils interagissent.

Selon les études réalisées par les analystes de Google, cinq facteurs impactent l’efficacité d’une équipe, classés ici par ordre d’importance. Source : Google re:Work Guide: Understand team effectiveness

Dans le cadre du projet Aristote, des centaines d’équipes Google ont été interrogées sur la question suivante : « Qu'est-ce qui rend une équipe efficace ? ». L'analyse statistique des données recueillies a révélé que la dynamique d'équipe la plus importante est la sécurité psychologique, c'est-à-dire la création d'un environnement où la prise de risques intelligents est encouragée. Autrement dit, un climat de travail dans lequel les collaborateurs sont convaincus qu'ils ne seront pas embarrassés ou sanctionnés pour leurs idées, leurs questions ou leurs erreurs.

Une analyse plus poussée de DORA montre que ces pratiques ne bénéficient pas uniquement aux équipes de Google : la culture de la « sécurité psychologique » permet d’obtenir de bien meilleurs résultats en matière de livraison logicielle, de performance organisationnelle et de productivité.

Enfin, il est important de rappeler que la culture d’une entreprise découle du management. La recherche DORA montre qu'un leadership efficace a un impact mesurable et significatif sur la livraison logicielle. Pour favoriser un climat psychologiquement sûr, où les reproches n’ont pas leur place, les dirigeants doivent accorder à leurs équipes la confiance nécessaire, leur permettre de s'exprimer et leur donner la possibilité d'expérimenter et d'échouer.

Comment, en pratique, améliorer votre résilience ?

Adopter une posture d’amélioration continue peut aider à obtenir de meilleures performances organisationnelles. De même, l'adoption de la sécurité psychologique dans votre organisation peut aider vos équipes à travailler plus efficacement. De notre point de vue, ces deux approches constituent les fondements d’une résilience qui favorise la réussite par la culture.

Alors, à quoi ressemble la résilience lorsqu'elle est appliquée concrètement dans nos comportements et renforcée dans notre travail quotidien ?

Nous pouvons nous améliorer continuellement en démarrant rapidement les projets, en définissant des indicateurs de réussite, en collectant des informations (y compris par le biais du crowdsourcing) et en valorisant ce que nous apprenons, à la fois pour améliorer nos produits et notre façon de travailler. Cette approche peut être renforcée par des pratiques techniques telles que l'intégration continue, les tests automatisés, la livraison continue, l’observabilité et le monitoring, pour n'en citer que quelques-unes. Ces pratiques constituent à la fois les fondations et les garde-fous qui favorisent une itération sûre, rapide et fiable.

Nous pouvons aussi normaliser l'échec en organisant des « pré-mortems », sorte d’analyse en vue d’anticiper les innombrables façons dont une idée peut échouer, et des « post-mortems sans reproches » (analyses a posteriori). L’idée étant d’avoir des conversations franches sur les moments où les choses ne se sont pas déroulées comme prévu en imaginant les leviers qui auraient pu être actionnés pour améliorer la situation. Le tout sans faire de reproche à qui que ce soit.

Nous avons, par exemple, constaté que les équipes qui encouragent des « pratiques de fiabilité », y compris des postmortems sans reproches, font état d’une meilleure productivité et d’une satisfaction professionnelle plus élevées. Elles affichent également un taux d'épuisement professionnel plus faible que leurs homologues qui utilisent des approches opérationnelles plus traditionnelles. Nous pensons que cela s'explique notamment par le fait qu'une peur persistante de commettre des erreurs peut entraîner un certain mal-être.

Les analyses a posteriori sans reproches permettent d'éviter que les problèmes se reproduisent, d’éviter d’engendrer plus de complexité et d'apprendre de ses erreurs et de celles des autres.

Ces méthodes de travail sont illustrées par nos derniers lauréats du Google Cloud DevOps Award. Ils ont montré comment ils mettent en œuvre ces pratiques (et d'autres) pour favoriser la réussite de leur organisation et se montrer plus performants. Typiquement, imaginez une entreprise qui s’appuie sur des équipes interfonctionnelles pour éliminer les goulets d'étranglement, débloquer des situations et améliorer la communication. Nous aurons l’occasion d’y revenir dans un prochain article.

En attendant, entraînez-vous à l'échec en expérimentant de nouvelles méthodes de travail, y compris en testant de nouvelles approches sur la livraison logicielle, l’opérationnel, etc. Et posez-vous la question suivante : comment réagirez-vous la prochaine fois que quelque chose ne fonctionnera pas ?

Pour en savoir plus, faites le DevOps Quick Check et lisez le dernier rapport sur l'état des DevOps, tous deux disponibles sur dora.dev.

Mais, au fait, où en est-on de la transformation digitale ?

Mon, 29 Jan 2024 06:00:00 +0000

La transformation numérique… But ultime pour se forger un avenir prospère dans le monde de demain, cette notion est au cœur des discussions depuis des années. Mais, concrètement, où en sommes-nous dans la quête à la numérisation ?

Excellente question ! Pour pouvoir y répondre, commençons par revenir aux fondamentaux de cette transformation que l’on nous vante sur tous les fronts. Numérique ou digitale, la transformation est avant tout là pour apporter plus de valeur aux clients, aux collaborateurs et aux actionnaires. Dit autrement, et pour faire court, l’objectif est clairement d’industrialiser les processus manuels existants en les optimisant grâce aux technologies. La finalité ultime étant, bien entendu, de mettre l’outil de production au service de la stratégie de l’entreprise, qu’il s’agisse de répondre, voire anticiper, les attentes du client, d’innover et d’accroître sa compétitivité sur le marché grâce à l’agilité apportée par des processus numérisés.

Confronté à une concurrence particulièrement rude, le secteur des services - banques, commerce, assurances, divertissement, etc. – est particulièrement en pointe sur le sujet. Et pour cause ! Dans ce secteur, les « Digital Native », autrement dit les entreprises nées à l’ère d’Internet, y sont particulièrement présentes. Affranchies d’un existant informatique qui freine toute transformation, mais aussi d’infrastructures physiques qui amputent leurs coûts opérationnels, elles capitalisent sur l’abonnement, modèle économique particulièrement apprécié par le client. Au cœur de leur stratégie, l’application, qu’elle soit Web ou mobile, est la clé du succès. Commande, renouvellement, gestion d’incident…quel que soit le processus, l’application doit répondre aux attentes du client. Et si le processus n’est pas optimal et correctement géré de bout en bout, le client est perdu ! Dans le monde des Digital Natives qui réussissent, les recherches inefficaces, les problèmes d’authentification, les interfaces peu intuitives ou encore les redirections vers un numéro de téléphone, une autre application ou un autre site qui découragent le chaland, n’ont clairement pas leur place.

Face aux géants du commerce en ligne, la grande distribution a très rapidement réagi, capitalisant sur les technologies pour mettre en place de nouvelles stratégies commerciales exploitant le canal numérique.

Aujourd’hui, on constate une effervescence côté banques, assurances, mutuelles où la modernisation applicative apparaît obligatoire pour accompagner les nouveaux usages. De fait, qui se déplace encore chez son assureur historique pour assurer son animal de compagnie ? Et pourquoi solliciter son banquier habituel pour financer l’acquisition d’un véhicule alors qu’une LOA est naturellement proposée par le constructeur automobile ?

Dès lors, on comprend aisément que, dans les grands groupes du tertiaire, la transformation digitale est déjà clairement amorcée. Elle se traduit notamment par un portefeuille applicatif moderne ou en cours de modernisation. Les autres industries ne sont pas en reste : dans les starting-blocks, elles se doivent d’embrasser ce changement culturel, visant à faire mieux, plus vite et moins cher avec le patrimoine applicatif de l’entreprise.

Avec le recul, on devrait parler de transformation applicative plutôt que de transformation digitale. Car l’application est désormais au centre de la stratégie d’entreprises, tant elle impacte les équipes, la culture et l’efficacité, mais aussi l’expérience des utilisateurs, qu’ils soient collaborateurs ou clients. La prise de conscience est là : pour gagner en agilité, la majorité des entreprises ont mis en place des "digital factory", développé des approches DevOps et adopté des plateformes technologiques pour héberger ces nouvelles applications. Malgré tout, elles sont confrontées à des difficultés…

Les coûts de l’infrastructure

Comme souvent, les entreprises se retranchent derrière les coûts, considérés comme le premier frein à la transformation applicative. Elles sont convaincues de maîtriser parfaitement leurs coûts d’infrastructure, ainsi que le budget alloué à l’évolution (relative) et au maintien en condition opérationnelle de leur application. En revanche, dès qu’elles se tournent vers le cloud, la projection montre une augmentation significative des coûts. Sauf que leur perception est faussée car bien souvent, elles comparent une bonne vieille carte routière au format papier à un GPS de dernière génération. Certes, la carte routière permet de trouver un itinéraire, mais elle est loin d’être pratique : il faut la déplier, elle se déchire, elle peut être obsolète, il en faut parfois plusieurs… Alors qu'avec un GPS, la cartographie est à jour et, en plus, l’application mémorise mes centres d'intérêt et me guide vocalement. Oui, le GPS est plus cher, mais offre des fonctionnalités avancées et une meilleure expérience d’utilisation. Dit autrement, la transformation par le cloud coûte plus ou moins cher, mais elle fait passer l’entreprise de l’âge de la carte routière à celui du GPS et lui permet d’apporter :

Plus de valeur ajoutée à l’utilisateur en lui proposant un service disponible, fluide, innovant et sécurisé
Plus d’efficience pour les équipes en simplifiant les développements et les opérations
Plus d’innovation pour rester en avance sur les concurrents et gagner des parts de marché

Dans quel domaine doit-on optimiser sa stratégie ?

Pour identifier les domaines prioritaires sur lesquels, en 2024, baser votre stratégie de transformation applicative afin d’en tirer le meilleur parti possible, voici quelques pistes incontournables :

Optimisation / containerisation

L’infrastructure, qu’elle soit matérielle, virtuelle ou containerisée, peut être optimisée en basculant sur des clusters Kubernetes managés tels que Google Kubernetes Engine (GKE) ou bien sur des services de plus haut niveau, dits "serverless", tels que Cloud Run.
L’usage de conteneurs permet de réduire l’empreinte de l’application en termes de ressources. Mais les bénéfices sont également opérationnels et financiers : plusieurs clusters peuvent être administrés d’une même console, la sécurité est native et avancée, le dimensionnement s’adapte à l’usage, etc.

APIsation

Pour enrichir l’application, l’utilisation de services externes peut avoir une forte valeur ajoutée voire être une nécessité. Par exemple, proposer à l’utilisateur l’intégration d’une cartographie, le suivi de son colis ou l’ajout de données statistiques s'avère indispensable, mais aussi très complexe à mettre en œuvre si on ne s’appuie pas sur des partenaires proposant ces derniers comme des services à consommer, généralement via des APIs.
Ainsi, une brique de gestion des APis telle que Apigee permet de créer, de gérer, de monétiser et de sécuriser des API pour tous les cas d'usage, internes comme externes. Cette solution permet également de publier des (micro)services pour des partenaires et ainsi ouvrir une partie des assets applicatifs à de nouveaux canaux.

IA et Gen AI

Pour beaucoup d'entre nous, l’intelligence artificielle semble magique ! En fait, elle EST magique dans le sens où elle est capable de trouver des tendances ou des patterns dans un référentiel de données tellement complexe, tellement volumineux que nous sommes incapables de l’exploiter avec des moyens informatiques classiques, et encore moins de l’appréhender avec nos yeux humains.

Elle peut dès lors apporter une incroyable valeur ajoutée d’un point de vue métier en valorisant des données jusqu’ici inexploitées. La seule limite est votre créativité.

Typiquement, l’IA peut permettre de:

Générer des campagnes marketing dont le contenu - mixant texte, image, vidéo - est spécifiquement adapté au profil ciblé, offrant ainsi de bien meilleurs résultats.
Résumer ou synthétiser des documents volumineux, des résultats ou même des tendances.
Proposer une recommandation de produits et services beaucoup mieux adaptés au prospect naviguant sur un site e-commerce, boostant ainsi les taux de conversion.
Implémenter une maintenance prédictive, évitant des surcoûts inutiles et les pannes.
Permettre des conversations naturelles basées sur une base de connaissance.

Pour développer et entraîner un modèle IA, il faut de la donnée, beaucoup de données. Le processus est long, complexe et coûteux en termes de ressources requises. Mais l’IA et l’IA générative sont maintenant plus accessibles puisque proposées sous forme de services managés, s’appuyant sur des centaines de modèles préentraînés, capables de reproduire une voix, de soutenir une conversation, de générer des images plus vraies que nature, de générer du code informatique, etc.

Avec Vertex AI, Google Cloud procure un service simple et pratique pour entraîner, personnaliser et déployer des modèles à utiliser dans vos applications basées sur l'IA. En complément, son nouveau « super assistant » Duet AI, prêt à l’emploi et intégré aux différents services GCP, accompagne les équipes sur la sécurité, le développement, les opérations, la gestion des données, etc., améliorant ainsi la productivité de celles-ci.

Sécurité de bout en bout

Comme nous l’avons vu plus haut, l’application doit être disponible et sécurisée pour s’assurer que ni les données de l’utilisateur ni les données de l’entreprise ne sont exposées. La sécurité apportée par l’infrastructure Cloud est indispensable, mais elle n’est pas suffisante. En effet, si les développeurs utilisent des librairies corrompues, si le cycle d’intégration et de déploiement n’est pas parfaitement maîtrisé, l’entreprise peut mettre en production une application présentant de graves failles compromettant les sécurités en place et la protection des données.
La sécurité doit donc être intégrée de bout en bout, sur l’ensemble du cycle de développement de déploiement.

Fort de son expérience dans ce domaine, Google Cloud propose une solution complète et managée : Software Delivery Shield (SDS) permet de contrôler les composantes open source, d’intégrer des packages validés, d’utiliser une chaîne CI/CD basée sur SLSA, de signer/autoriser les binaires, etc.

En complément, Cloud Workstation offre aux développeurs un environnement sécurisé, évolutif et personnalisé en fonction des projets permettant ainsi de s’affranchir des problématiques liées aux stations de développement (délai d'approvisionnement et de paramétrage, disparité des configurations, obsolescence, perte/vol, coût) qui limitent l'efficacité des équipes de développement.

Les axes de modernisation des applications sont donc nombreux et variés, rendant obsolète un projet unique de modernisation. Plutôt que de suivre une approche classique – voire ancestrale – de projet, avec des objectifs, un budget, et une durée définis à l’avance, mieux vaut opter pour une stratégie de modernisation continue. Cette dernière privilégie des mises à jour simples et régulières, évitant ainsi les changements complexes et risqués.

Cette approche favorise le changement tout en permettant de tirer des leçons à chaque itération et de gagner progressivement en maturité.

Elle favorise une étroite collaboration entre les équipes pour identifier les améliorations nécessaires, évaluer leurs avantages potentiels (comme la disponibilité, l'innovation, la sécurité, et les fonctionnalités uniques), mais aussi estimer le retour sur investissement afin de prioriser ces améliorations.

Une telle approche présente au final deux avantages. D'abord, elle est financièrement avantageuse, car elle évite de moderniser des éléments qui n'en ont pas besoin. Ensuite, elle permet une modernisation transversale (impliquant le développement, la sécurité, les opérations et les affaires), ce qui fédère les équipes autour de l'application et donc du Business.

Bonne transformation applicative !

Google nommé leader des plateformes de Functions-As-A-Service par Forrester

Thu, 07 Sep 2023 08:00:00 +0000

En 2016, nous avons lancé Cloud Functions, une solution permettant aux développeurs de concevoir facilement des applications hautement évolutives axées sur la programmation événementielle sans qu’ils aient à se préoccuper de l'infrastructure. Né de notre volonté de fournir un environnement flexible qui accélère les développements, le service serverless Cloud Functions répond également aux besoins de portabilité de nos clients et s’inscrit dans notre stratégie de cloud ouvert.

Tirant parti de nos innovations, telles que Functions Frameworks et Buildpacks, notre plateforme Functions-As-A-Service (FaaS) est le reflet de notre engagement en faveur de l’open source. Nous sommes donc d’autant plus ravis d’avoir été classés parmi les leaders mondiaux du FaaS dans le dernier rapport The Forrester Wave™: Functions-As-A-Service, Q2 2023.

Faire évoluer les limites du FaaS

En 2022, nous avons augmenté le potentiel de notre plateforme FaaS en annonçant Cloud Functions 2nd gen, une nouvelle version qui propose des fonctionnalités de traitement encore plus puissantes et très efficientes :

Intégration aux événements provenant de plus de 140 sources GCP, tierces ou personnalisées via le service de gestion d’événements Eventarc ;
Des workloads HTTP plus endurants avec un temps d’exécution pouvant aller jusqu'à 60 minutes ;
Plus de mémoire et de CPU attribués aux workloads : jusqu’à 32 Go de RAM et 8 vCPU ;
Traitement simultané de multiples requêtes (jusqu'à 1 000) avec une seule instance, ce qui réduit considérablement les démarrages à froid, améliore la latence et diminue les coûts.

L’approche « container-first » de Cloud Functions ‘2nd gen’ permet aux clients exploitant notre solution FaaS d’exécuter les traitements sur GCP mais également sur site (on-premises) dans leurs datacenters ou sur une autre plateforme cloud. Elle permet aussi de basculer les workloads de Cloud Functions à Cloud Run et Google Kubernetes Engine. Plus économique, cette approche vous évite d’avoir à adapter vos workloads si jamais vous souhaitez les déplacer d’une plateforme à l’autre.

Points forts relevés par le rapport Forrester

Google fait partie des neuf entreprises que Forrester a sélectionnées dans son évaluation 2023. Nous avons obtenu les meilleures notes possibles dans les critères Vision, Adoption et Observabilité. Cloud Functions a également été salué pour sa roadmap, obtenant sur ce critère le meilleur score parmi tous les fournisseurs évalués. « Impressionnante, la roadmap [de Cloud Functions] prévoit notamment l’expansion à de multiples régions et un meilleur support pour les entreprises », indique Forrester.

Gestion des workloads spécialisés

Dans son rapport, Forrester souligne aussi que Cloud Functions est « la seule plateforme autorisant les clients à configurer l'allocation mémoire et CPU de manière totalement indépendante, ce qui renforce sa capacité à gérer des workloads spécialisés ».

Ainsi, Cloud Functions obtient une note de 4,20 / 5 sur le critère « gestion des workloads spécialisés », soit la note la plus élevée de tous les fournisseurs sélectionnés. Nous sommes convaincus que cette note salue nos efforts pour proposer une plateforme puissante qui intègre les solutions AI et ML de Google Cloud, dont la génération de prédictions avec les modèles ML de Vertex AI ou encore la création d’applications de reconnaissance optique des caractères (OCR) avec Vision API. De plus, Cloud Functions gère le streaming de données en temps réel (real-time data streaming), fonctionnalité adaptée à de nombreux cas d’usages dont la détection des fraudes.

En indiquant que « Google Cloud Functions se distingue par sa flexibilité de configuration du matériel et des types d’instances », Forrester met également en évidence la capacité de Cloud Functions à prendre en charge des workloads centrés sur le contenu, à commencer par le support de Google Cloud CDN.

Intégration à tout l’univers Google Cloud

Notre plateforme FaaS est capable de gérer un large éventail de cas d’usage dans Google Cloud, et nos « investissements dans la plateforme managée Firebase pour les applications web et mobiles élargissent encore le spectre d’application de la plateforme FaaS », note Forrester dans son rapport. Disponible depuis peu, Firebase Functions 2nd gen est une solution puissante dont l’infrastructure a été améliorée et qui propose une plus grande couverture d’événements. Nous avons également lancé Firebase Extensions, un ensemble de solutions serverless pré-packagées s’appuyant sur Cloud Functions.

Dit autrement, Cloud Functions est aussi un puissant outil sur lequel vous pouvez vous appuyer pour étendre et automatiser vos services Google Cloud. BigQuery Remote Functions en est un exemple concret. Cette récente innovation vous permet d’étendre BigQuery SQL en y ajoutant vos propres fonctions hébergées dans Cloud Functions. Concrètement, vous pouvez ainsi enrichir des données BigQuery en temps réel en appelant des API externes, exploiter des modèles dans Vertex AI ou autres plateformes ML ou encore appliquer simplement un chiffrement et une tokenisation de données.

Nous sommes ravis et honorés d'avoir été nommés « leader » par Forrester dans son nouveau rapport The Forrester Wave™ Functions-As-A-Service Q2 2023. Si vous souhaitez tester Cloud Functions, n’hésitez pas à profiter de l'offre « Free Tier » de Google Cloud.

Modernisation applicative : Votre projet de plateforme est-il voué à l'échec ?

Wed, 23 Aug 2023 07:00:00 +0000

Dans un récent article de notre nouvelle rubrique « The Modernization Imperative (TMI) », Richard Seroter mettait en évidence l’avantage du « shifting down rather than shifting left » (déplacement vers le bas plutôt que vers la gauche). Cette méthode vise à tirer au maximum parti des fonctionnalités embarquées dans les plateformes utilisées afin d’alléger la charge de travail des développeurs et des opérateurs. En tant que conseiller auprès des responsables ingénierie des projets de modernisation dans le cloud, je partage pleinement son point de vue. Toutefois, si votre organisation compte construire sa propre plateforme (et par extension l’équipe IT qui va avec), rendez-vous service en vous posant quelques questions clés avant même de démarrer.

Créer ses propres plateformes technologiques en interne semble être devenu une pratique très en vogue dans les entreprises ces derniers temps. Et pour cause : elles permettent aux équipes IT d'être plus productives et plus autonomes, tout en centralisant la gouvernance et la gestion de la sécurité. Non seulement, le cloud est lui-même une plateforme (d’où le nom GCP, Google Cloud Platform) mais c’est aussi l’opportunité idéale d’y développer et déployer une multitude de plateformes complémentaires, qu’il s’agisse de plateformes de données avec BigQuery, de plateformes ML/AI avec Vertex AI, de plateformes de gestion d’APIs avec Apigee, ou encore de plateformes multi-tenant d’exécution de conteneurs avec Google Kubernetes Engine. Dit autrement dit, on assiste aujourd’hui à un phénomène de superposition et d’imbrications de plateformes !

Pour un DSI ou un architecte d'entreprise, investir dans le déploiement d’une plateforme présente des avantages évidents. Mais il y a un hic : personne d'autre dans l’entreprise ne s'intéresse à votre plateforme. Car ce n’est pas parce que vous avez déployé une belle plateforme prête à l’emploi que les utilisateurs vont nécessairement se jeter dessus.

Vous pouvez bien sûr forcer les gens à utiliser votre plateforme. Mais vous n’aurez alors atteint votre objectif qu’à moitié : tandis que vous avancez en centralisant votre gouvernance et en optimisant votre posture de sécurité, vos utilisateurs reculent car vous les obligez à apprendre, à s’équiper et à adopter une solution qu’ils n’ont pas demandée et dont ils n’ont (subjectivement) pas besoin. Une plateforme qu’ils détesteront par défaut, avant même de commencer à l’utiliser. Si leur expérience n'est pas parfaite (et la perfection n’est pas de ce monde), ils rejetteront la faute sur la plateforme et sur vous.

Alors quels sont vos moyens pour encourager l’adoption, voire l’adoption massive de votre solution ? L’implémentation de nouvelles plateformes internes est-elle systématiquement vouée à l’échec ? Fort heureusement, non !

De fait, afin de maximiser vos chances de succès, vous devrez avant tout développement vous poser ces trois questions essentielles : Pour qui construisez-vous la plateforme ? Qui va la construire ? Et enfin, comment allez-vous en mesurer le succès ?

Question 1 : Pour qui construisez-vous ?

« Commencez par l'utilisateur et travaillez en sens inverse ». Ce conseil, nous l’avons tous entendu. Mais, dans les grandes entreprises, il n’est pas toujours évident à suivre. En pratique, l’utilisateur réel de l’infrastructure est souvent un collaborateur d’un autre service dont les besoins sont exprimés par son chef de service ou le chef produit. Ces derniers interagissent ensuite avec le « responsable de l’infrastructure X » qui privilégie les fonctionnalités de backlog et délègue le design d’architecture à un architecte d’entreprise qui, à son tour, conseille les ingénieurs sur la conception de l’infrastructure. Vous l’aurez compris, à ce stade, plus personne ne se souvent des besoins réels de l’utilisateur !

Pour éviter d’en arriver là, voilà comment vous auriez dû aborder le problème : les ingénieurs qui mettent en œuvre l’infrastructure doivent régulièrement rencontrer l'utilisateur final en face à face, ce dernier étant accompagné par le chef produit de son service. Toutes les personnes impliquées dans la création ou l’exploitation de l’infrastructure doivent tenir dans une seule pièce - ou au moins tenir sur un seul écran "Meet/Zoom/Teams". C’est d’ailleurs la raison pour laquelle la meilleure des plateformes est souvent celle que les gens se sont auto-créée : vous pouvez difficilement être plus proche de l’utilisateur quand l’utilisateur, c’est vous.

Si avoir toutes les parties prenantes dans la même pièce est impossible, vous pouvez aussi vous appuyer sur un outil puissant : les « user watch parties » ou séances d’observation des utilisateurs. Le principe est simple : réunis dans une pièce, les ingénieurs observent l’utilisateur pendant qu'il interagit avec la plateforme dans la pièce voisine à travers un miroir sans tain.

En réalité, il suffit d’enregistrer tout ce qui se passe sur leur écran et leurs remarques, en ayant bien entendu demandé leur accord au préalable. Recrutez cinq utilisateurs qui veulent bien se prêter à l’expérience et donnez-leur deux ou trois objectifs identiques à atteindre en utilisant l'ancienne plateforme que vous souhaitez remplacer ou la version MVP (Minimum Viable Product, ou Produit Minimum Viable) de celle que vous envisagez de construire. Demandez-leur de réfléchir à haute voix et d'exprimer toutes les suppositions qu'ils font et toutes les difficultés qu'ils peuvent éprouver.

Vous serez alors surpris de constater que même l'utilisateur le plus intelligent et le plus avisé prendra plus de temps que vous ne le pensiez et se retrouvera bloqué à des endroits auxquels vous n’auriez jamais pensé. Vous pourriez être tenté de rejeter ces réactions « anecdotiques » en les qualifiant d'aberrantes. Vous pourriez également imaginer qu'une documentation plus claire et une formation supplémentaire pourraient faire disparaître ces réactions. Mais la réalité est toute autre : vous assistez au véritable défi à relever par votre nouvelle plateforme : elle doit plaire à vos utilisateurs et rendre leur travail plus facile.

Les « user watch parties » présentent également l'avantage d'aligner toute votre équipe d'ingénieurs sur les mêmes priorités, pour la simple raison qu’ils viennent de partager les mêmes observations. Alors qu’avant la « user watch party » chaque membre de l’équipe pouvait avoir sa propre prochaine fonctionnalité favorite à construire, une fois la réunion terminée, il deviendra douloureusement évident que c’est bien une fonctionnalité existante qui méritera en priorité toute l’attention de l’équipe.

Question 2 : Qui va la construire ?

Avoir des idées, c’est facile. Les concrétiser, c’est plus difficile. Si vous n’abordez pas la question de manière critique, l’équipe qui construira la plateforme sera celle qui en a eu l’idée.
La pilule pourra parfois paraître difficile à avaler, mais n’oublions pas que l’enjeu ne tourne pas autour de vous, de vos ingénieurs en charge de la plateforme, du « Head of Platforms » (responsable des Plateformes) ou même du DSI : l’enjeu est centré sur l’utilisateur. Vous devez donc former une équipe infrastructure capable de satisfaire les besoins des utilisateurs en premier lieu, et vos ambitions personnelles ensuite.

Se pose alors la question de l’équipe idéale. Pour faire court, l’équipe plateforme idéale est dédiée au projet, petite et polyvalente. Il vaut mieux n’avoir que trois ingénieurs qui se consacrent exclusivement à la plateforme plutôt que 10 qui ont d’autres priorités et consacrent leur peu de temps libre au projet. Et oui, cette équipe suppose des effectifs dédiés et un sponsor exécutif fort, de sorte à encourager ses membres dès les premières phases de développement. C’est la manière dont toutes les entreprises « digital native » fonctionnent pour construire leurs plateformes et vous devez vous en inspirer.

La création d'une plateforme est un défi d'apprentissage, pas un défi d'exécution : les retours d'information rapides et l'apprentissage partagé sont essentiels à la réussite de l'équipe. Physiquement ou virtuellement, les membres de l’équipe doivent pouvoir travailler dans la plus grande proximité et dépendre au minimum d’autres équipes. Cette proximité est également essentielle pour éviter de tomber dans le piège du « ce n’est pas mon travail », chaque membre n’acceptant alors que les tâches qui relèvent de son expertise ou de la mission rattachée à son poste. En adoptant un état d’esprit du type « montre-moi comment on fait », l’équipe confie naturellement la tâche à l’expert mais s’attend aussi à ce que tous ses membres soient capables de relever n'importe quel défi technique.

Enfin, il n’est pas impossible que vous ayez besoin de l’autorisation du RSSI, de l’architecte d’entreprise, etc., avant de pouvoir utiliser certains services. N’hésitez pas à intégrer ces personnes (ou un de leur représentant) dans l’équipe en lui accordant un rôle essentiel, au moins jusqu’à ce que leur contribution soit intégrée au projet sous forme de règle codée (Policy as Code) ou de schémas (blueprints) d’architecture.

Question 3 : Comment mesurer le succès ?

Rien ne sert de respecter les délais et le budget impartis si c’est pour aboutir à une plateforme que personne n’utilise. Pour éviter un tel écueil, ne mesurez pas les réussites de votre équipe en fonction d’indicateurs de performance projet (Project KPIs). Optez plutôt en faveur d’indicateurs produits (Product KPIs) qui mesurent son utilité, le taux d’adoption ou encore la satisfaction des utilisateurs.

Il n’existe pas réellement de méthode universelle pour mesurer le succès d'un logiciel mais en obtenant des réponses à ces questions, vous pourrez quantifier sa réussite :

Combien de temps faut-il à l'utilisateur pour atteindre son objectif ? (moins = mieux)
Combien d'utilisateurs utilisent la plateforme et à quelle fréquence ? (plus = mieux)
Quels sont le degré de satisfaction des utilisateurs et la probabilité qu'ils recommandent la plateforme à d'autres employés ?

Chez Google, nous aimons utiliser le framework H.E.A.R.T. pour évaluer l’expérience utilisateur d’un grand nombre de nos produits grand public. Nous utilisons également un framework modifié que nous avons baptisé S.U.P.E.R. pour certaines de nos infrastructures informatiques internes :

Partez à la rencontre de vos utilisateurs

Nous sommes convaincus que la proximité avec les utilisateurs est primordiale lors de la construction d’une infrastructure. Et nous avons expliqué plus haut comment retrouver une partie de cette proximité perdue en organisant des « user watch parties ». Nous avons également souligné l’importance des équipes polyvalentes et indiqué comment les inciter à construire une plateforme pertinente qui facilite réellement le travail des utilisateurs, plutôt que de se contenter de finaliser un projet informatique avant de passer au suivant.

Bien entendu, nous avons ici à peine effleuré l’étendue de ce que signifie planifier, réaliser et gérer avec succès une plateforme pertinente en tant que produit. Il y aurait encore beaucoup à dire sur l'importance des profils d'utilisateurs, la cartographie du parcours de l'utilisateur et le véritable rôle du chef produit, pour ne citer que ces quelques points.

De fait, si vous ne devez retenir qu’une seule chose de cet article, gardez à l’esprit que vous ne savez pas ce dont vos utilisateurs ont besoin et ce qu'ils veulent. Vous n'avez que des hypothèses, que vous devez vérifier. Et ce n'est pas parce que vous construisez la « bonne » plateforme qu'ils l’adopteront forcément. Vous devez impérativement aller à leur rencontre.

Faciliter le passage à Google Cloud et à des technologies Open Source

Mon, 12 Jun 2023 08:00:00 +0000

Pendant des décennies, avant que le cloud ne vienne bouleverser notre vision des bases de données et des applications, Oracle et SQL Server constituaient la clef de voûte des infrastructures applicatives des entreprises. Mais aujourd’hui, alors que vous entamez votre redéploiement vers le cloud, vous réévaluez probablement les choix effectués autrefois à la lumière des tendances actuelles et des vastes opportunités offertes par le cloud.

Dans le domaine des bases de données, plusieurs hypothèses s’offrent à vous : adoption des technologies open source (en particulier MySQL, PostgreSQL et leurs dérivés), bases de données non relationnelles, stratégies multicloud et cloud hybrides… pour supporter des applications à la fois globales et qui fonctionnent en 24/7.
Redéploiement rapide de type « lift-and-shift », modernisation d’un existant ou transformation complète avec adoption d’une base « cloud first » … selon l’application, l’évolution vers le cloud peut prendre des chemins différents.

Google Cloud propose un ensemble de services de bases de données managées qui couvrent les moteurs des bases open source mais également des bases provenant de tiers ainsi que les bases « cloud-first ». Nous avons publié cinq vidéos spécialement destinées aux clients qui cherchent à passer au cloud ou à se libérer complètement des problématiques de gestion des licences et autres restrictions. Nous espérons que ces vidéos vous permettront de mieux évaluer vos options, que vous envisagiez un redéploiement homogène (en utilisant la même base de données qu'aujourd'hui) ou un redéploiement hétérogène (en passant à un moteur de base de données différent).

Voici les cinq vidéos en question :

#1 Exécuter des applications Oracle Database dans Google Cloud

Par Jagdeep Singh et Andy Colvin

Migrer vers le cloud peut s’avérer difficile si l’activité de votre entreprise repose sur des applications fonctionnant avec des bases de données Oracle. Cette dépendance peut s’expliquer par des problématiques de licences, de compatibilité ou encore d’administration.
À travers cette vidéo, nous vous proposons de découvrir différentes options proposées par Google Cloud et adaptées à cette situation, qu’il s’agisse de Bare Metal Solution for Oracle (solution matérielle certifiée et optimisée pour les workloads Oracle) ou de solutions émanant de partenaires tels VMware et Equinix. Profitez-en pour découvrir comment vous pouvez continuer à exécuter votre existant dans le cloud tout en capitalisant sur les dernières avancées technologiques pour développer de nouveaux services.

#2 Exécuter des applications SQL Server dans Google Cloud

Par Isabella Lubin

Aujourd’hui encore, Microsoft SQL Server reste une base très populaire en entreprise. Apprenez à exécuter SQL Server de manière fiable et sécurisée avec Cloud SQL, un service de base de données entièrement managé permettant d'exécuter des workloads MySQL, PostgreSQL et SQL Server. Plus de 90 % des 100 plus gros clients de Google Cloud utilisent Cloud SQL. Autrement dit, les plus grandes entreprises du monde font aujourd’hui confiance à Cloud SQL. Dans cette vidéo, nous vous proposons de découvrir comment sélectionner la bonne instance de base de données, comment migrer votre base, comment travailler avec les outils SQL Server standards ou encore comment superviser votre base et la maintenir à jour.

#3 Opter pour une base PostgreSQL dans Google Cloud

Par Mohsin Imam

Plébiscitée pour la souplesse de son modèle de licence open source, sa richesse fonctionnelle, ses solides références ou encore pour l’étendue de sa communauté de développeurs et de ses outils, PostgreSQL est une base relationnelle leader sur le marché. Google Cloud propose, aux utilisateurs de PostgreSQL, trois services de bases de données entièrement managés:
* Cloud SQL, un service de base de données entièrement managé et facile à utiliser pour PostgreSQL open source ;
* AlloyDB, un service de base de données compatible avec PostgreSQL pour les applications nécessitant plus d'évolutivité, de disponibilité et de performances;
* et Cloud Spanner, une base de données "cloud-first" avec une montée en charge illimitée, une disponibilité de 99,999 % et une interface PostgreSQL.
Découvrez quelle solution convient le mieux à votre application, comment migrer votre base de données vers le cloud et comment bien démarrer.

#4 Comment migrer et moderniser vos applications avec les bases de données Google Cloud

Par Sandeep Brahmarouthu

Le redéploiement de vos applications et bases de données vers le cloud n'est pas toujours facile. Si des workloads simples peuvent se contenter d’un simple transfert de SGBD sur le mode « lift-and-shift », les applications d'entreprise de plus grande envergure et personnalisées ont, en revanche, parfois besoin d’être modernisées, voire entièrement transformées. Découvrez les services managés de bases de données proposés par Google Cloud ainsi que notre approche de la « modernisation progressive ». Explorez également nos frameworks de redéploiement pour bases de données et découvrez comment nous pouvons vous aider à mieux démarrer, avec notre offre gratuite d’évaluation des risques.

#5 Bien démarrer avec Database Migration Service

Par Shachar Guz & Inna Weiner

L’augmentation des coûts de maintenance peut aussi être une excellente raison de migrer ses bases vers le cloud. Que vous envisagiez un simple transfert, une modernisation avec adoption d’une alternative plus moderne et open source ou une transformation complète d’une application, Google Cloud peut vous accompagner dans votre démarche. Découvrez comment Database Migration Service simplifie votre modernisation par le cloud avec son approche serverless et sa plateforme sécurisée qui s’appuie sur des mécanismes de réplication native afin d’effectuer des redéploiements plus fidèles et plus fiables. Moins complexe, le redéploiement est aussi moins long et moins risqué. Résultat, vous pouvez redémarrer en moins d’une heure après le redéploiement…

Nous avons hâte de vous aider à réussir votre redéploiement

Quelle que soit votre approche du cloud, nous avons la solution pour vous accompagner dans votre démarche avec des bases de données évolutives, fiables, sécurisées et ouvertes. Nous sommes d’ores et déjà enchantés à l’idée d’offrir un nouveau « foyer » à vos applications.

N’hésitez pas à profiter de l’offre d’essai gratuite pour explorer les avantages de Cloud SQL ou Spanner et accélérer votre redéploiement vers Google Cloud avec Database Migration Program.

Mesurer et maximiser la valeur des équipes de data science et IA

Fri, 04 Nov 2022 06:00:00 +0000

Investir dans l'intelligence artificielle (IA) peut apporter un avantage concurrentiel à votre organisation. Si vous avez la charge d'une équipe IA ou data science, vous avez sans doute envie de mesurer et maximiser la valeur que vous apportez. Voici quelques conseils tirés de nos années d'expérience dans ce domaine. Ils se focalisent sur deux aspects de tout projet : sa préparation et les métriques à mettre en place dès le démarrage…

Notre checklist à appliquer à tous vos projets

Avant tout décollage, il faut vérifier la checklist. Un principe aussi vrai dans l’aviation que dans la data science. Autrement dit, avant de vous lancer dans un projet, assurez-vous d’avoir bien couvert tous les domaines ci-dessous :

Avoir un client. Il est important d'avoir un client pour votre travail, et qu'il soit d'accord avec ce que vous essayez d'accomplir. Assurez-vous de connaître la valeur que vous espérez lui apporter.
Réaliser une analyse de rentabilité. Elle devra reposer sur des estimations et des hypothèses et ne prendra pas plus de quelques minutes de votre temps. Vous pouvez la réviser, mais sachez toujours ce qui justifie les efforts de votre équipe et ce que vous (et votre client) attendez en retour.
Identifier le processus que vous allez modifier ou créer. Le fruit de votre travail va passer en production. Il est donc essentiel de savoir clairement comment votre travail va impacter les opérations métier et qui doit être impliqué dans le processus pour concrétiser votre démarche.
Mettre un plan de mesures en place. Pour montrer que votre travail a un impact sur un indicateur métier pertinent, mesurez et affichez la valeur ajoutée. L’objectif est de mettre en évidence le différentiel entre ce qui est désormais possible et ce qui ne l’était pas sans votre travail. N’oubliez pas de prendre en compte tous les facteurs qui peuvent affecter vos mesures, telles la saisonnalité ou d’autres évolutions des activités.

Utilisez cette checklist pour vous aider à obtenir le soutien de votre organisation, tant au niveau de l’équipe que du projet.

Quelles mesures utiliser ?

Dès le début du travail effectif, pensez à mettre en place des mesures et indicateurs démontrant que le travail de votre équipe est utile à votre organisation. Voici quelques exemples universels :

Nombre de décisions prises. Un des points forts du ML est d'automatiser et d'optimiser la prise de décision : quel produit recommandé, quel itinéraire suivre, etc. Utilisez des journaux de logs pour savoir combien de décisions votre solution est capable de prendre.
Impact sur les revenus et les coûts. De meilleures décisions prises plus rapidement entraînent souvent une augmentation des revenus ou des économies. Si possible, mesurez-les directement. Sinon, estimez-les en calculant, par exemple, le carburant économisé grâce à la réduction de la distance parcourue ou l’augmentation des ventes grâce aux offres personnalisées.
À titre d’exemple, le département de la sécurité de l'emploi de l'Illinois utilise l'IA dans son centre de contact pour déployer rapidement des agents virtuels afin d'aider plus d'un million de citoyens à déposer leurs demandes de chômage. Pour mesurer le succès du projet, l’équipe a utilisé deux indicateurs : (1) le nombre de demandes de renseignements sur le Web et d'appels vocaux qu'elle a pu traiter, et (2) le coût global du centre d'appels après la mise en œuvre de l’IA.
Après déploiement du projet, elle a ainsi pu constater qu’ils traitaient plus de 140 000 demandes de renseignements par téléphone et par Internet par jour et plus de 40 000 appels par nuit (en dehors des heures de bureau). Sur la base d'une première analyse des données relatives aux agents virtuels IDES (pour plus de détail, consultez notre étude de cas), ils anticipent une économie annuelle estimée à 100 millions de dollars.
Coûts de mise en œuvre. Vous pouvez également aborder le sujet de l’augmentation des revenus ou des économies réalisées en replaçant les résultats obtenus face aux coûts de vos réalisations. Indiquez les coûts engendrés par votre équipe en les comparant à la valeur apportée et en précisant comment vous pourriez encore apporter davantage de valeur.
Gains de temps. Si votre équipe construit un système de routage, elle fait économiser du temps de déplacement. Si elle construit un classificateur automatique d'e-mails, elle fait économiser du temps en lecture… Quantifier le nombre d’heures gagnées pour votre entreprise grâce à l’efficacité de la solution que vous avez construite.
À titre d’exemple, la rapidité des diagnostics est particulièrement importante dans le domaine médical. La division BIOS (Brain Injury Outcomes) de l'université Johns Hopkins s'est concentrée sur l'étude des hémorragies cérébrales afin d'améliorer les résultats médicaux. L'équipe a identifié le temps de compréhension comme une mesure clé du succès du projet. Elle a expérimenté une série de solutions de cloud computing comme Dataflow, Cloud Healthcare API, Compute Engine et AI Platform pour un entraînement distribué accélérant les itérations. Grâce à leurs travaux récents portant sur les photos scanners d'environ 500 patients, ils ont réduit le temps nécessaire à l’élaboration d’un diagnostic à 90 minutes environ, contre 2 500 heures auparavant.
Nombre d’applications produites par votre équipe. Certaines opérations réalisées au sein de l’entreprise, comme le rapprochement comptable, n’ont pas besoin de ML. Mais d’autres processus peuvent en bénéficier. Identifiez combien de services profitent des optimisations et des automatisations que votre équipe a mises en place.
Expérience utilisateur. Vous pouvez peut-être mesurer l'expérience de vos clients : moins de plaintes, de meilleures évaluations, une latence réduite, plus d'interactions, etc. Ceci est valable aussi bien pour les utilisateurs internes qu’externes. Typiquement, chez Google, nous mesurons l'utilisation et demandons régulièrement un retour d'information sur tout système ou processus interne.
Un de nos clients, la ville de Memphis, utilise VisionAI et le ML pour gérer un problème banal mais néanmoins complexe, à savoir l'identification et le traitement des nids-de-poule. L’équipe a retenu les indicateurs de performance suivants : le taux d’augmentation des nids-de-poule identifiés, la précision et les économies réalisées. La solution capture les séquences vidéo enregistrées par ses véhicules publics et exploite les capacités de Google Cloud comme Compute Engine, AI Platform et BigQuery pour automatiser l’analyse des vidéos. Le projet a augmenté la détection des nids-de-poule de 75 % avec une précision de plus de 90 %. En mesurant et en affichant ces résultats, l'équipe a prouvé la viabilité d'un modèle ML rentable basé dans le cloud. Elle envisage de nouvelles applications de l'IA et du ML pour améliorer encore les services de la ville et l'aider à construire un meilleur avenir pour ses 652 000 habitants.

Remerciements

Filipe et Payam tiennent à remercier leur collègue et co-auteur Mona Mona (Ingénieur client AI/ML, Soins de santé et sciences de la vie) qui a contribué à parts égales à la rédaction de cet article.

Un redéploiement simplifiée des données mainframe vers le cloud

Tue, 30 Aug 2022 09:00:00 +0000

Les mainframes d'IBM existent depuis les années 1950 et demeurent encore essentiels dans de nombreuses organisations. Ces dernières années, certaines d’entre elles ont cependant entrepris un redéploiement de leurs workloads vers le cloud. Cette démarche de modernisation est motivée à la fois par le besoin de rester pertinent, par la pénurie croissante d'experts en mainframes et par les économies promises par les solutions de cloud computing.

L'un des principaux défis du redéploiement des mainframes a toujours été le transfert des données de ces derniers vers le cloud. Heureusement, Google offre en libre accès son connecteur « bigquery-zos-mainframe » pour concrétiser de tels transferts avec un effort minimal.

À la découverte du connecteur Mainframe pour BigQuery et Cloud Storage ?

Le connecteur Mainframe permet aux utilisateurs de Google Cloud de transférer des données mainframes vers Cloud Storage et de soumettre des tâches BigQuery à partir de jobs mainframes codés en JCL (le langage de contrôle des jobs des mainframes). Grâce à l'interpréteur Shell inclus et aux versions JVM des utilitaires de ligne de commande gsutil et bq, les équipes mainframes peuvent aisément gérer un pipeline ELT complet entièrement depuis z/OS.

Le connecteur déplace les données situées sur un mainframe vers - et depuis - Cloud Storage et BigQuery. Il transcode ces jeux de données directement au format ORC (un format pris en charge par BigQuery). En outre, il permet aux utilisateurs d'exécuter des tâches BigQuery à partir de JCL, de sorte que les jobs mainframes puissent tirer parti de certains des services les plus puissants de Google Cloud.

Ce connecteur a été testé avec des fichiers plats créés par IBM DB2 EXPORT qui contiennent des champs de caractères binary-integer, packed-decimal et EBCDIC et qui peuvent être facilement représentés par un CopyBook (un fichier de description de données classiquement employé dans l’univers mainframes sous Cobol et DB2).
Les clients disposant de fichiers VSAM peuvent utiliser IDCAMS REPRO pour exporter ces données vers des fichiers plats, ces derniers pouvant ensuite être téléchargés à l'aide du connecteur.
Notez que le transcodage vers ORC nécessite un CopyBook et que tous les enregistrements doivent avoir la même mise en page. Si la mise en page est variable, le transcodage ne fonctionnera pas, mais il est toujours possible de télécharger directement une simple copie binaire du jeu de données.

Comment utiliser le connecteur bigquery-zos-mainframe ?

Un workflow de mise en œuvre du connecteur mainframe comprend en général les étapes suivantes :

- Lecture du jeu de données mainframe

- Transcodage du jeu de données en ORC

- Téléchargement de l'ORC vers Cloud Storage

- Enregistrement de cet ORC en tant que table externe

- Exécution d'une instruction DML MERGE pour charger de nouvelles données incrémentielles dans la table cible (sur le cloud).

Notez que si le jeu de données ne nécessite pas de modifications supplémentaires après le chargement, il est préférable d’opter pour un chargement dans une table native plutôt qu’une table externe.

En ce qui concerne l'étape 2, il est important de mentionner que les exportations DB2 sont écrites sous forme de jeux de données séquentiels sur le mainframe et que le connecteur utilise le CopyBook du jeu de données pour le transcoder en ORC.

L'exemple simplifié ci-dessous montre comment lire un jeu de données sur un mainframe, le transcoder au format ORC, copier le fichier ORC sur Cloud Storage, le charger dans une table native BigQuery et exécuter une commande SQL sur cette table.

1 – Vérifier et compiler

code_block: <ListValue: [StructValue([('code', 'git clone https://github.com/GoogleCloudPlatform/professional-services\r\ncd ./professional-services/tools/bigquery-zos-mainframe-connector/\r\n \r\n# compile util library and publish to local maven/ivy cache\r\ncd mainframe-util\r\nsbt publishLocal\r\n \r\n# build jar with all dependencies included\r\ncd ../gszutil\r\nsbt assembly'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1bb7ec7880>)])]>

2 - Téléchargez l’assembly jar qui vient d'être créé dans target/scala-2.13 vers un chemin du système de fichiers unix de votre mainframe.

3- Installez la Procédure JCL BQSH sur n’importe quel jeu de données partitionné sur le mainframe que vous souhaitez utiliser comme PROCLIB. Modifiez la procédure pour mettre à jour le classpath Java avec le chemin du système de fichiers unix où vous avez téléchargé l'assembly jar. Vous pouvez modifier la procédure pour définir toute variable d'environnement spécifique à votre infrastructure.

4- Créer le Job

Etape 1

code_block: <ListValue: [StructValue([('code', '//STEP01 EXEC BQSH\r\n//INFILE DD DSN=PATH.TO.FILENAME,DISP=SHR\r\n//COPYBOOK DD DISP=SHR,DSN=PATH.TO.COPYBOOK\r\n//STDIN DD *\r\ngsutil cp --replace gs://bucket/my_table.orc\r\n/*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1bb7ec78e0>)])]>

Cette étape lit le jeu de données dans INFILE DD et lit le modèle d'enregistrement dans COPYBOOK DD. Le jeu de données d'entrée peut être un fichier plat exporté depuis IBM DB2 ou un fichier VSAM. Les enregistrements lus à partir du jeu de données d'entrée sont écrits dans le fichier ORC à l'adresse gs://bucket/my_table.orc avec le nombre de partitions déterminé par la quantité de données.

Etape 2

code_block: <ListValue: [StructValue([('code', '//STEP02 EXEC BQSH\r\n//STDIN DD *\r\nbq load --project_id=myproject \\\r\n myproject:MY_DATASET.MY_TABLE \\\r\n gs://bucket/my_table.orc/*\r\n/*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1bb7ec7940>)])]>

Cette étape soumet un job BigQuery qui chargera les partitions de fichiers ORC de « my_table.orc » dans MY_DATASET.MY_TABLE. Notez que le chemin est bien celui utilisé à l'étape précédente.

Etape 3

code_block: <ListValue: [StructValue([('code', '//STEP03 EXEC BQSH\r\n//QUERY DD DSN=PATH.TO.QUERY,DISP=SHR\r\n//STDIN DD *\r\nbq query --project_id=myproject\r\n/*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1bb7ec79a0>)])]>

Cette étape soumet un job de requêtage BigQuery (Request Job) pour exécuter une lecture SQL à partir du QUERY DD (un fichier FB au format LRECL 80). En général, la requête sera une instruction MERGE ou SELECT INTO qui entraîne la transformation d'une table BigQuery.
Note : le connecteur enregistrera les métriques du job mais n'écrira pas les résultats de la requête dans un fichier.

Fonctionner hors du mainframe pour économiser les MIPS

Sur un système de production, planifier des tâches générant de larges transferts de données n’est pas une chose à prendre à la légère.
Il est important de retenir que le connecteur Mainframe s'exécute dans un processus JVM et devrait donc utiliser les processeurs zIIP par défaut, mais si la capacité est épuisée, l'utilisation peut s'étendre aux processeurs généraux.
Étant donné que le transcodage d'enregistrements z/OS et l'écriture de partitions de fichiers ORC nécessitent une quantité non négligeable de traitements, le Mainframe Connector comprend un serveur gRPC conçu pour gérer les opérations de calcul intensif sur un serveur cloud (une instance VM sur Google Cloud Engine). En activant cette fonctionnalité, les traitements intensifs sont réalisés hors du mainframe sur un serveur cloud, le processus exécuté sur z/OS se contentant de télécharger le jeu de données vers Cloud Storage et d’effectuer un appel RPC.
Le passage du connecteur d’un mode d'exécution locale à un mode d’exécution distante ne nécessite qu'un changement de variable d'environnement. Des informations détaillées sur cette fonctionnalité sont disponibles ici.

Remerciements

Merci à ceux qui ont testé, débogué, maintenu et amélioré cet outil : Timothy Manuel, Catherine Im, Madhavi Kancharla, Suresh Balakrishnan, Viktor Fedinchuk, Pavlo Kravets.

Libérez le potentiel de vos données sur mainframe avec une approche innovante : la « data-first digitization »

Tue, 24 May 2022 08:00:00 +0000

Dans de nombreuses entreprises, de vénérables mainframes abritent encore des décennies de données sur les clients, les processus et les opérations. Et bien évidemment, ces entreprises aimeraient bien pouvoir y accéder pour effectuer des analyses et créer des rapports avec les outils du big data ou encore pour les utiliser dans le cadre de nouveaux projets de Machine Learning et d’Intelligence Artificielle.

Nous avons hâte chez Google de vous accompagner dans cette démarche en vous aidant à transformer les ressources mainframe pour l'ère du cloud. Nous pouvons bien entendu vous aider à moderniser vos applications mainframes en les faisant migrer vers le cloud. Mais en parallèle, nous avons aussi développé une autre alternative avec nos partenaires et nos clients. Plus légère, elle permet de commencer à exploiter les ressources des mainframes sur le cloud beaucoup plus rapidement qu’avec une migration complète de l’existant. Nous avons baptisé cette approche data-first digitization ou, en français, « numérisation des données d'abord ».

Dans un monde numérique qui évolue rapidement, il convient tout d’abord de faire la différence entre « modernisation » et « numérisation ».
Dans une approche classique de modernisation, vous partez de l’existant pour vous projeter dans l’avenir en vous appuyant sur des méthodes de migration d’applications des mainframes, qu’il s’agisse de rehosting (émulation), de refactoring (transformation du code), de réingénierie ou simplement de remplacement d'une application sur mesure par une solution « clés en main ».
À l’inverse, dans une approche « numérisation », on part du résultat attendu et on remonte la chaîne existante en modifiant tout ce qui doit l’être pour atteindre son objectif.

Cette approche « numérisation » s’appuie sur un framework d’intégration privilégiant les données. Constitué à partir de nos outils et solutions et ceux de nos partenaires, il permet de migrer des sources de données hétérogènes provenant des mainframes vers Google Cloud Storage. Une fois les données mainframe copiées sur Cloud Storage, elles peuvent ensuite être intégrées et exploitées par les outils Google Cloud, tels que BigQuery, les solutions d'IA et de Machine Learning ou encore les plateformes d’analyse intelligente (Smart analytics) et d’analyse de flux (Stream analytics).
Notre framework d'intégration couvre à la fois le mode batch pour transférer d’un coup des jeux de données volumineux et la réplication en temps réel par capture des modifications apportées aux données (prise en charge du « change data capture »).

L’approche « numérisation d’abord » repose sur le principe selon lequel « les applications sont éphémères, les données sont permanentes ».

Plutôt que d’utiliser les méthodes traditionnelles de modernisation telles que décrites dans les 7 options de modernisation du Gartner par exemple, les entreprises vont ici privilégier le transfert des données vers Google Cloud, ce qui leur permettra d’accélérer les étapes et de commencer à mettre rapidement en place nouveaux modèles métiers, de nouveaux cas d’usage ou encore de nouvelles façons innovantes de satisfaire leurs clients.

Deux exemples concrets :

Prendre de meilleures décisions, plus rapidement, en s’appuyant sur les solutions d’analyse en temps réel et intelligentes mais aussi sur les moteurs de Machines Learning et/ou AI. Google est un pionnier dans l'extraction d'informations et de valeur à partir de données brutes structurées et non structurées. Ces outils ont toutefois besoin d’être alimentés en données pour gagner en efficacité. En rendant les données sur mainframe accessibles par des outils comme BigQuery et des modèles AI/ML, les entreprises maximisent leurs capacités d’analyse.
Créer de nouvelles applications de reporting. L’accessibilité des données sur mainframe par des outils Google Cloud, tels que Looker et Appsheet, permet de créer de nouvelles applications de reporting et ainsi d’accélérer votre transformation globale en décommissionnant plus rapidement les anciennes applications de reporting hébergées sur mainframe.

D'après notre expérience, l'adoption d'une approche « numérisation » axée sur les données offre un certain nombre d'avantages :

Réactivité métier : cette forme de modernisation s’appuyant sur des outils existants, le cycle de mise en œuvre est beaucoup plus court.
Investissements réduits : l’intégration de produits est moins consommatrice de ressources que le développement d’applications.
Risques minimisés : la démarche data-first repose sur des solutions intégrées aux produits Google Cloud existants, éprouvés et fiables.
Transformation plus rapide de l’existant sur mainframe : en déplaçant le centre de gravité de l’application vers les données, vous abordez la question de la modernisation sous l’angle métier, plutôt que de simplement continuer à faire vivre cet existant. Dès lors, seules les applications réellement critiques pour l’entreprise sont modernisées tandis que les applications non essentielles peuvent être mises hors service progressivement, ce qui permet d’accélérer le processus de transformation.

Une telle numérisation centrée sur les données est encore une approche relativement récente, mais les premiers succès de nos clients nous invitent à poursuivre dans cette voie.
N’hésitez pas à consulter régulièrement sur notre site pour obtenir des informations supplémentaires, des architectures de référence et des livres blancs techniques sur l'approche "data-first". Et si vous pensez qu’elle peut vous convenir, contactez mailto:mainframe@google.com.

Optimisez vos applications avec Google Vertex AI Vizier

Tue, 05 Apr 2022 09:00:00 +0000

Les innovations en intelligence artificielle (IA) et en apprentissage machine (ML) profitent aujourd’hui aux entreprises du monde entier. Chez F5, nous utilisons beaucoup l'IA et le ML pour améliorer la sécurité des données, la détection des fraudes ou encore la prévention des attaques de robots, avec des bénéfices à la clef clairement identifiés. Nous utilisons également l'IA et le ML pour optimiser l’ingénierie logicielle.

L’utilisation de l’IA et du ML dans l’ingénierie logicielle en est encore à ses balbutiements. On commence à voir apparaître des cas d’usage autour de la programmation assistée par l’IA (code completion) ou encore autour de la génération automatique de code par les solutions no-code/low-code. Mais, pour l’instant, l’utilisation de l’IA et du ML pour optimiser l’architecture d’une application logicielle reste encore peu répandue. Dans ce billet, nous allons aborder l’amélioration d’un workload de pipeline de données en utilisant les principes d’optimisation d’une « Black-Box » à l’aide de Vertex AI Vizier de Google.

Pour rappel, on appelle « boîte noire » ou « black-box » le principe qui consiste à observer le comportement d’une tâche informatique à travers les résultats qu’elle produit et en fonction de différents paramètres donnés en entrée. Un tel principe est utilisé lorsqu’il n’est pas possible d’accéder à son fonctionnement interne. Les techniques BBO (Black-Box Optimization) cherchent à optimiser le fonctionnement de telles tâches dont on ne peut influer sur la conception mais dont le comportement peut varier en fonction de paramètres passés en entrée. L’optimisation de grands réseaux de neurones est un exemple typique de BBO.

Optimisation des performances

Processus itératif et essentiellement manuel, l'optimisation logicielle repose aujourd’hui surtout sur des « profileurs » (ou outils de profiling) qui identifient les goulots d'étranglement au sein du code source. Ces profileurs mesurent les performances et génèrent des rapports, utilisés ensuite par les développeurs pour optimiser leur code. Cette approche manuelle présente un inconvénient majeur : l’optimisation repose sur les compétences et l’expérience du développeur. Elle est donc très subjective. De plus, le processus est lent, non-exhaustif, et l’optimisation peut comporter des erreurs ou être sujette aux préjugés humains. La nature distribuée des applications cloud natives complique encore le processus d'optimisation manuelle.

En ingénierie de la performance, il existe une autre approche plus globale quoiqu’encore sous exploitée : elle repose sur les expérimentations de performance et les algorithmes d’optimisation des boîtes noires (algorithmes BBO). L’objectif consiste à optimiser le coût opérationnel d’un système complexe doté d’une multitude de paramètres. Signalons qu’il existe d’autres techniques d’optimisation des performances basées sur l’expérimentation, tel le profilage causal (Causal Profiling), mais elles sortent du cadre de cet article.

Un processus BBO d’optimisation des performances est par nature itératif et automatisé, comme l’illustre la figure 1. Une succession d'essais contrôlés est réalisée sur un système pour étudier la valeur d’une fonction « coût » caractérisant le système à optimiser. De nouveaux paramètres possibles sont générés et d’autres essais sont réalisés jusqu’à ce que l’amélioration soit trop infime pour être rentable (cf plus loin).

Figure 1 : Optimisation en Boîte Noire : des expérimentations successives pour arriver à un résultat optimal sur une fonction “côut”

Quel est le problème ?

Commençons par planter le décor – inspiré en partie de notre propre expérience mais aussi en partie fictif pour mieux illustrer le propos.

Notre objectif ici est de construire un moyen efficace de transférer des données de PubSub vers BigQuery. Google Cloud propose un service entièrement managé de traitement des données, Dataflow, pour l'exécution d'une grande variété de modèles de traitement des données, que nous utilisons pour de nombreux autres besoins de streaming en temps réel.

Dans le cadre de cet article, nous avons choisi de tirer parti d'un processeur de flux personnalisé simplifié - une sorte de modèle "E(t)LT" - afin de traiter et de transformer les données tout en bénéficiant de l'orientation "en colonnes" de BigQuery.

La configuration mise en œuvre est illustrée plus en détail figure 2. Le notebook central joue le rôle d'orchestrateur pour l'étude du "système à optimiser". Les principaux objectifs (et composants impliqués) sont les suivants :

Reproductibilité : en plus d'un processus automatisé, un snapshot pub/sub est utilisé pour initialiser un abonnement spécifiquement créé pour alimenter le processeur de flux afin de reproduire les mêmes conditions pour chaque expérience.
Évolutivité : Vertex AI Workbench met en œuvre un ensemble de procédures automatisées utilisées pour exécuter plusieurs expériences en parallèle avec différents paramètres d'entrée afin d'accélérer le processus d'optimisation global.
Déboguabilité : pour chaque expérience, les identifiants de l'étude et de l'essai sont systématiquement injectés comme étiquettes pour chaque log et métrique produits par le processeur de flux. De cette façon, nous pouvons facilement isoler, analyser et comprendre les raisons de l’échec ou de résultats surprenants ou incohérents d'une expérience.

Figure 2 : représentation de haut niveau de l’architecture utilisée pour réaliser nos expérimentations

Pour transférer efficacement les données de PubSub vers BigQuery, nous avons conçu et développé un code que nous voulons maintenant affiner pour qu'il soit le plus performant possible. Nous disposons d'un programme que nous voulons l'optimiser en nous basant sur des mesures de performance faciles à obtenir en l'exécutant. Notre question est maintenant de savoir comment sélectionner la meilleure variante.

Sans surprise, il s'agit là d'un problème typique d'optimisation : le monde en est rempli ! Essentiellement, ces problèmes consistent à optimiser (minimiser ou maximiser) une fonction « objectif » sous certaines contraintes et à trouver où les minima ou maxima se produisent.

De telles pratiques d’optimisation sont applicables à de nombreux domaines.

La formule est classique :

En d'autres termes, nous voulons les x d'un certain domaine X qui minimisent une fonction « coût » f. Comme il s'agit ici d'un problème de minimisation, de tels x sont appelés minima. Les minima n'existent pas nécessairement et lorsqu'ils existent, ils ne sont pas nécessairement uniques.

Bien sûr, tous les problèmes d'optimisation ne sont pas égaux : la programmation linéaire et continue est "facile", l'optimisation convexe est aussi relativement facile, mais l'optimisation combinatoire est un art plus complexe... Elle présuppose que l’on puisse décrire la fonction « objectif » que nous voulons optimiser - même partiellement, par exemple en étant capable de calculer les gradients.

Dans notre cas, la fonction « objectif » (autrement dit la fonction qui modélise l’objectif recherché) est une certaine performance (qui reste encore à déterminer à ce stade) d'un programme dans un certain environnement d'exécution.

On est donc loin ici d’un classique « f(x)=x2 » : nous n'avons pas d'expression analytique pour la performance de notre programme, pas de dérivées, aucune garantie que la fonction est convexe, l'évaluation est coûteuse et l'observation peut être « bruitée ».

Ce type d'optimisation est appelé « optimisation en boîte noire » pour la raison que nous ne pouvons pas décrire notre fonction « objectif » en termes mathématiques simples. Néanmoins, nous sommes très intéressés par la recherche des paramètres qui donnent le meilleur résultat.

Avant d'introduire l'optimisation de la boîte noire, commençons d’abord par définir notre situation comme un problème d'optimisation concret.

Nous évoquerons ensuite les outils utilisés car il nous faut un moyen d'automatiser la résolution de ce type de problèmes plutôt que de le faire manuellement : "le temps, c'est de l'argent", comme on dit.

Définition d’un problème d'optimisation

Notre problème comporte de nombreux éléments « mobiles », mais tous n'ont pas la même nature.

Objectif

Tout d'abord, l'objectif. Dans notre cas, nous voulons minimiser le coût par octet du transfert des données de PubSub vers BigQuery. En supposant que le système évolue linéairement dans le domaine qui nous intéresse, le coût par octet traité est indépendant du nombre d'instances. Ce qui permet d'extrapoler précisément le coût pour atteindre un débit défini.

Comment y arriver ?

Nous exécutons notre programme sur un volume significatif et connu de données dans un environnement d'exécution spécifié - pensez à un type de machine, un emplacement et une configuration de programme spécifiques -. Nous mesurons alors le temps qu'il faut pour traiter ce volume de données et nous calculons le coût des ressources - nommé `cost_dollar` ci-dessous. C'est notre fonction « coût » f.

Comme nous l'avons mentionné précédemment, il n'existe pas d'expression mathématique simple pour définir la fonction « coût » de notre système. Son évaluation implique donc l'exécution d'un programme, ce qui est en soi "coûteux".

Espace des paramètres

Notre système comporte de nombreux boutons sur lesquels agir : le programme possède de nombreux paramètres de configuration correspondant à des façons alternatives de faire les choses que nous voulons explorer et des paramètres de dimensionnement tels que la taille de la file d'attente ou le nombre de workers.

L'environnement d'exécution définit encore plus de paramètres : La configuration de la VM, le type de machine, l'image du système d'exploitation, l'emplacement, ...

En général, le nombre de paramètres peut varier énormément - pour ce scénario, nous en avons une douzaine.

Au final, notre espace de paramètres est décrit par la Table 1 qui pour chaque `parameter_id` donne le type de valeur (entier, discret ou catégorique).

Voilà donc notre objectif identifié. Et nous savons comment l'évaluer en affectant une collection de paramètres identifiés. Nous avons même défini le domaine de ces paramètres.

Tout est donc désormais en place pour nous permettre de réaliser une optimisation en boîte noire.

Notre Approche

Maintenant que le décor est planté, revenons à nos moutons : l'optimisation en boîte noire. Comme déjà évoqué, il s'agit d'un problème de minimisation/maximisation d'une fonction pour laquelle nous n'avons pas d'expression. Nous pouvons néanmoins l'évaluer ! Il nous suffit de réaliser une expérience et d'en déterminer le coût.

Le problème est que l'exécution de l'expérience a elle-même un coût. Étant donné l'étendue des paramètres, les explorer tous n'est pas une option viable. En supposant que vous ne choisissiez que 3 valeurs pour chacun des 12 paramètres environ, cela donne 312, autrement dit 531 441 combinaisons possibles et donc 531 441 expérimentations à tester. C'est déjà beaucoup trop ! Cette méthode d'exploration systématique de toutes les combinaisons générées à partir d'un sous-ensemble de chaque paramètre pris individuellement est appelée « recherche par grille » (ou Grid Search).

À la place, nous allons utiliser une forme d'optimisation de substitution : Dans un cas comme celui-ci où il n'y a pas de représentation commode de notre fonction « objectif », il peut être bénéfique d'introduire une fonction de substitution avec de meilleures propriétés qui modélise la fonction réelle.

Certes, au lieu d'un seul problème : minimiser notre fonction « coût », nous en avons désormais deux : adapter une fonction à notre problème et la minimiser.

Mais nous avons acquis une recette pour aller de l'avant : adapter un modèle aux observations et utiliser ce modèle pour aider à choisir un candidat prometteur pour lequel nous devons mener une expérience. Une fois que nous avons le résultat de l'expérience, le modèle peut être affiné et de nouveaux candidats peuvent être générés, jusqu'à ce que les améliorations se révèlent marginales et ne valent plus la peine.

Et justement, Google Cloud Vertex AI Vizier propose ce type d'optimisation sous forme « as a service ». Si vous voulez en savoir plus sur ce qui se cache derrière - spoiler : Google s'appuie sur l'optimisation par processus gaussien (GP) - consultez cette publication pour une description complète : Google Vizier : un service d'optimisation en boîte noire.

En pratique, nous avons réalisé 148 expériences différentes avec différentes combinaisons de paramètres d'entrée. Qu'avons-nous appris ?

Les résultats de notre étude

Le but de ce billet n'est pas de détailler précisément les paramètres que nous avons utilisés pour obtenir le meilleur coût - ce n'est en effet pas une information transférable car votre programme, votre configuration et à peu près tout le reste seront différents.

Ce que nous souhaitons, c’est vous donner une idée du potentiel de la méthode : dans notre cas, avec 148 cycles, notre fonction « coût » est passée de 0,0780 $/cycle avec notre configuration initiale supposée à 0,0443 $/cycle avec les meilleurs paramètres - soit une réduction des coûts de 43 % ! Sans surprise, le paramètre `machine_type` joue ici un rôle majeur ici. Mais même avec le même type de machine que celui offrant les meilleurs résultats, la partie (explorée) de notre fonction « coût » varie entre $0.0443/run et $0.0531/run - une variation de 16% qui est loin d’être négligeable.

Les runs les plus prometteurs sont représentés dans la figure 3. Tous les axes, sauf les deux derniers, correspondent à des paramètres. Les deux derniers représentent respectivement l'objectif `cost_dollar`, et si le run s'est terminé ou non. Les lignes représentent les runs successifs et relient entre elles les valeurs de chaque axe qui leur correspondent.

Dit autrement, nous avons découvert une amélioration substantielle des coûts avec presque aucune intervention de notre part. Nous allons explorer cet aspect plus en détail dans la section suivante.

Qu’avons-nous appris ?

L'un des principaux avantages de cette méthode est qu'elle peut fonctionner de manière autonome et ne nécessiter que peu ou pas d'intervention humaine. À condition, bien sûr, d’avoir fait l'effort initial de configurer les choses correctement.

L'optimisation en boîte noire suppose que l'évaluation de f(x) ne dépende que de x et non de ce qui se passe au même moment. Nous ne voulons pas voir d'interactions entre les différentes évaluations de f(x).

L'une des principales applications de Vizier est l'optimisation des hyperparamètres des modèles d'apprentissage profond. La formation et l'évaluation sont essentiellement dépourvues d'effets secondaires - coût mis à part, mais nous avons déjà dit que les méthodes d'optimisation en boîte noire supposent que l'évaluation est coûteuse et sont conçues de sorte à réduire le nombre d'exécutions nécessaires pour trouver les paramètres optimaux. Notre scénario a définitivement des effets secondaires : il déplace des données d'un endroit à un autre.

Donc, si nous nous assurons que tous les effets secondaires sont supprimés de notre expérience de performance, la vie devrait être facile pour nous. Dès lors, les méthodes d'optimisation de type boîte noire peuvent s'appliquer et Vizier en particulier peut être utilisé.

Pour supprimer les effets secondaires, nous avons enveloppé l'exécution de notre scénario dans une logique de mise en place et de démantèlement d'un environnement isolé.

Quelques leçons sur l'exécution de ce type de tests méritent d'être soulignées :

Il faut tout paramétrer, même s'il n'y a qu'une seule valeur au départ : si une autre valeur devient nécessaire, il est facile de l'ajouter. Dans le pire des cas, les valeurs sont enregistrées avec vos données, ce qui facilite la comparaison entre différentes expériences si nécessaire.
Il faut veiller à l’isolation entre les exécutions (runs) et d'autres choses : si une telle isolation n'est pas paramétrée et qu'elle a un impact sur l'objectif, les mesures seront « bruitées » et il sera plus difficile pour le processus d'optimisation d'être décisif lors de la prochaine exploration.
Il faut veiller à l’isolation entre les exécutions (runs) simultanées : de sorte que l’on puisse exécuter plusieurs expériences à la fois.
Il faut s’assurer de la robustesse des exécutions (runs) : toutes les combinaisons de paramètres ne sont pas réalisables, et Vizier permet de les signaler comme telles.
Il faut s’assurer d’un nombre suffisant d’exécutions (runs) : Vizier s'appuie sur les résultats des expériences précédentes pour décider de ce qu'il faut explorer ensuite et vous pouvez demander à ce qu'un certain nombre d'expériences soient exécutées en même temps - sans avoir à fournir les mesures. C'est utile pour commencer à exécuter des expériences en parallèle, mais d'après notre expérience, c'est aussi utile pour s'assurer que vous avez une large couverture de l'espace des paramètres avant que l'exploration ne commence pour essayer d'identifier les extrema locaux. Par exemple, dans la série d'exécutions que nous avons décrite plus haut dans ce billet, 'n2-highcpu-4' n'a pas été essayé avant l'exécution 107.
Des outils existent aujourd'hui : Vizier est un exemple disponible sous forme de service. Il existe également de nombreuses bibliothèques Python pour l'optimisation en boîte noire. Il s'agit d'un outil à avoir dans sa boîte à outils si l'on ne veut pas passer des heures à manipuler manuellement des paramètres et que l'on préfère une machine pour le faire.

Conclusion et prochaines étapes

L'optimisation en boîte noire est inévitable pour le réglage des hyperparamètres ML. Google Vertex AI Vizier est un service d'optimisation en boîte noire avec une gamme d'applications plus large. Nous pensons qu'il s'agit également d'un excellent outil pour l'ingénierie de systèmes complexes caractérisés par de nombreux paramètres dont les interactions sont essentiellement inconnues ou difficiles à décrire.

Bien sûr, pour les petits systèmes, l'exploration manuelle et/ou systématique des paramètres peut être possible, mais l'intérêt de ce billet est de rappeler qu'elle peut aussi être automatisée !

L'optimisation des performances est un défi récurrent car tout change et de nouvelles options et/ou de nouveaux modes d'utilisation apparaissent.

La configuration présentée dans ce billet est relativement simple et très statique. Il existe des extensions naturelles de cette configuration à l'optimisation continue en ligne qui méritent d'être explorées du point de vue du génie logiciel, comme les « bandits à bras multiples ».

Et si l'avenir de l'optimisation des applications était déjà là, mais pas très bien réparti, pour paraphraser William Gibson ?

Vous pensez que tout ceci est définitivement très cool ? Alors, sachez que le groupe AI & Data de F5 recrute !