Vivre à la pointe : comment nous en sommes arrivés là

Ken Arora

Les développeurs et les ingénieurs qui viennent d’arriver dans le monde de l’informatique et des applications ont souvent tendance à voir le monde à travers le prisme de la toute dernière technologie, la plus récente et la plus prometteuse du moment. Pourtant, la vérité est le plus souvent que, tels les amis d’enfance des vieux briscards de l’industrie technologique que nous sommes, ces concepts et leurs mises en œuvre analogues ont toujours existé. Ils gagnent simplement du terrain ou en perdent au fil du temps, à mesure que les exigences métier et les réalités économiques convergent ou divergent au regard des contraintes de mise en œuvre et des infrastructures sous-jacentes. En réalité, c’est l’évolution constante de l’environnement économique qui fait naître les besoins et les exigences, conduisant ainsi à redécouvrir certaines stratégies technologiques ou à en écarter d’autres.

Dans cette optique, je consacrerai les prochains articles à certaines technologies liées aux applications qui prendront de l’ampleur au cours des prochaines années, notamment à mesure que nous évoluerons vers une infrastructure de diffusion des applications plus largement distribuée et que l’edge computing jouera un rôle croissant. Mais il convient d’abord d’examiner pourquoi et comment nous en sommes arrivés là.

Étape 1 : l’ère des centres de données

Commençons notre voyage il y a une vingtaine d’années, à une époque où les services aux entreprises étaient fournis sous forme numérique depuis des centres de données détenus et exploités par des entreprises privées (le terme « applications » n’était alors pas encore entré dans le langage courant). Cette stratégie technique était suffisante et adaptée à cette époque, principalement parce que seules les activités les plus critiques pour les entreprises étaient alors « numérisées ». Voici quelques exemples d’activités numériques de cette époque :

• Un commerçant en ligne ne « numérisait » que l’expérience d’achat des clients et, éventuellement, la gestion des stocks.
• Une compagnie aérienne se contenterait de « numériser » les systèmes de réservation et de paiement.
• Le gouvernement « numériserait » les processus transactionnels à forte valeur ajoutée, tels que le paiement des impôts.

Étant donné que seul un petit nombre de processus métier — c’est-à-dire les plus importants — étaient fournis sous forme numérique et envisagés dans le contexte d’une entreprise type de l’époque (des équipes intégrées verticalement et regroupées sur un même site, avec un contrôle centralisé de l’organisation et de l’infrastructure informatique), il était tout naturel que cela se traduise, sur le plan organisationnel, par un centre de données détenu de manière centralisée et géré par le service informatique, exécutant des « applications » monolithiques développées pour l’essentiel, voire entièrement, en interne. L’infrastructure, la sécurité et les applications (anciennement appelées « services métier ») formaient une pile unique intégrée verticalement. Ainsi, au sens propre, la pile technologique — centralisée et monolithique — reproduisait les structures organisationnelles et commerciales.

Étape 2 : l’ère du cloud

L’étape suivante de l’évolution des applications et de leur pile technologique a été portée par l’extension de la « numérisation » aux processus métier secondaires. Cette nouvelle étape a élargi l’éventail des processus numériques pour inclure non seulement ceux destinés aux clients — qui se sont par ailleurs banalisés, comme en témoigne la multiplication des applications dans les boutiques d’applications — mais aussi les processus opérationnels internes à l’organisation, souvent considérés comme faisant partie de la tendance à la transformation numérique des entreprises.

Par conséquent, les entreprises ont été contraintes de repenser leurs stratégies organisationnelles. Face aux variations rapides de leur activité, elles ont notamment accordé une plus grande importance à la maîtrise des coûts et à l’agilité. Cette évolution a favorisé un modèle de tarification à l’usage, consistant à ne payer que les ressources réellement consommées, plutôt que de devoir payer à l’avance et provisionner des capacités supérieures en prévision d’une éventuelle hausse de la charge. En termes financiers, le financement de l’infrastructure applicative est ainsi progressivement passé d’un modèle CapEx, fondé sur des investissements initiaux, à une stratégie OpEx de paiement à l’usage. Au cours de la même période, une autre tendance, également liée à la maîtrise des coûts et à l’agilité, a été l’évolution vers une main-d’œuvre davantage répartie géographiquement, ce qui a nécessité une connectivité disponible partout, plus fiable et accessible 24 h/24 et 7 j/7 qu’auparavant.

Les répercussions de ces exigences — la numérisation d’un nombre bien plus important de processus métier, la recherche de la flexibilité offerte par le modèle de coûts OpEx et la nécessité d’une connectivité mondiale disponible 24 h/24 et 7 j/7 — ont naturellement créé un environnement propice à la mise en place d’un réseau mondial de très grands centres de données virtuels à haute disponibilité, dont l’utilisation était facturée à l’usage. C’est ainsi qu’est né le cloud public.

En outre, une fois les bases du cloud public posées, une boucle de rétroaction positive auto-entretenue s’est mise en place. À mesure que le cloud public gagnait en maturité en tant que plateforme applicative, il a commencé à absorber une grande partie de l’infrastructure réseau de bas niveau auparavant gérée par les services informatiques traditionnels des entreprises. Par conséquent, le périmètre des équipes chargées des opérations réseau s’est réduit dans de nombreuses entreprises, qui ont préféré se concentrer sur le déploiement et la livraison des applications (« DevOps »), ainsi que sur la sécurité des applications (« SecOps »). Bien entendu, cette évolution n’a pas été universelle : les fournisseurs de services et les grandes entreprises avaient à la fois le besoin et les capacités nécessaires pour assurer en interne les opérations réseau (« NetOps ») liées à leurs workflows les plus critiques ou sensibles.

Cette évolution a marqué la première phase de l’ère du cloud, durant laquelle le cloud public pouvait être considéré comme une forme de centre de données externalisé, dont le temps et les ressources étaient mutualisés. En d’autres termes, le cloud public reposait sur le modèle de l’infrastructure en tant que service (IaaS).

La phase suivante de l’ère du cloud a été portée par l’émergence de deux constats commerciaux distincts, qui nécessitaient tous deux le paradigme de la phase 1/IaaS comme prérequis. Le premier de ces constats a été rendu possible par la capacité à dissocier la création de valeur pour l’entreprise de l’implémentation assurant l’exécution du flux de travail numérique. Plus précisément, les entreprises pouvaient désormais commencer à envisager une stratégie d’exécution dans laquelle les couches inférieures de l’infrastructure technologique — désormais gérées sous la forme d’un service fourni par le cloud public — pouvaient être dissociées des préoccupations principales des dirigeants, centrées sur la proposition de valeur de l’entreprise et ses facteurs de différenciation concurrentielle.

Le deuxième constat était qu’à mesure que les processus de travail traditionnels se numérisaient et s’automatisaient, les processus métier de plus haut niveau pouvaient être ajustés et optimisés dans des délais beaucoup plus courts. Un autre article examine cet effet plus en détail et explique comment les processus de travail numériques évoluent, passant de la simple automatisation des tâches à l’optimisation numérique (également appelée « expansion numérique »), pour aboutir finalement à des augmentations des capacités métier assistées par l’IA. Cette tendance s’observe dans des processus de travail aussi divers que l’ajustement des prix, la planification des horaires des employés et la gestion des stocks, qui ont tous bénéficié d’une capacité d’adaptation rapide, donnant ainsi naissance au terme « agilité métier ».

Ces deux constats ont provoqué une véritable prise de conscience dans le monde des affaires : les entreprises ont compris qu’il était souvent plus rentable d’externaliser les activités ne relevant pas de leur cœur de métier. Cette évolution a donné lieu à un partenariat gagnant-gagnant entre les entreprises et leurs fournisseurs de services cloud, les deux parties ayant intérêt à améliorer davantage les services proposés par le cloud public afin de décharger les entreprises d’une part encore plus importante de leurs contraintes technologiques. Le cloud public a ensuite étendu ce concept en proposant également sous forme de services des fonctionnalités de plateforme plus avancées, telles que des bases de données, des systèmes de fichiers, des passerelles API et des plateformes de calcul sans serveur. En outre, les fournisseurs de cloud public ont également proposé d’intégrer des services complémentaires, le plus souvent dans les domaines de la gestion des performances et de la sécurité.

Ainsi, à mesure que l’ère du cloud dépassait le modèle IaaS de la phase 1, elle a ouvert la voie aux paradigmes de la phase 2 du cloud : la plateforme en tant que service (PaaS) et le logiciel en tant que service (SaaS). Avec cette deuxième phase, la majeure partie, voire la totalité, de l’infrastructure nécessaire au fonctionnement d’une application pouvait être externalisée par l’entreprise auprès de fournisseurs de cloud capables d’optimiser l’infrastructure à grande échelle et de mobiliser une équipe plus importante de spécialistes pour se consacrer à tout service applicatif largement utilisé. Si cela permettait à l’entreprise de concentrer son budget technologique sur la logique métier fondamentale, cette approche entraînait souvent un effet secondaire indésirable, de son point de vue : une « dépendance » à l’égard d’un fournisseur de cloud particulier. Pour atténuer cet effet, les entreprises se sont efforcées de définir et de formaliser l’expression de leur valeur métier fondamentale à l’aide de technologies indépendantes des fournisseurs, notamment dans les domaines clés des API et des modèles de calcul. Ces technologies ont été mises en œuvre au moyen d’API REST et gRPC, reposant sur un modèle de calcul virtualisé et conteneurisé : Kubernetes.

Étape 3 : numérisation des objets et des processus physiques

La troisième étape, qui commence actuellement à émerger dans l’évolution des « applications », est portée par la numérisation d’activités quotidiennes que nous considérons rarement comme des flux de travail. Contrairement aux étapes 1 et 2, au cours desquelles ce sont principalement les processus métier et un nombre restreint de parcours transactionnels des consommateurs qui ont été mis en ligne, cette étape vise à créer des expériences numériques omniprésentes et parfaitement intégrées aux gestes de notre « vie humaine » quotidienne. L’ensemble des cas d’usage continue de se dessiner, mais les nouveaux cas d’usage qui s’appuient sur des technologies telles que la réalité augmentée, les systèmes automatisés de surveillance du domicile et la gestion de l’énergie à l’échelle du réseau nous donnent déjà un aperçu de la richesse et de la diversité des perspectives à venir. Ces solutions interagissent notamment avec le monde réel et physique, souvent au moyen d’appareils intelligents : véhicules autonomes, assistants numériques, caméras et toutes sortes d’appareils domestiques intelligents.

Du point de vue des entreprises, cette prochaine transition accordera une importance bien plus grande à l’expérience utilisateur du consommateur numérique. Cette priorité donnée à l’expérience utilisateur, associée au constat que les appareils, et non les humains, constitueront la majorité des clients directs des processus numériques, signifie que les exigences du consommateur numérique en matière d’expérience utilisateur seront beaucoup plus diverses qu’aux étapes précédentes de l’évolution numérique. Cette prochaine transition, de l’étape 2 à l’étape 3, sera différente de la précédente (de l’étape 1 à l’étape 2). Plus précisément, cette nouvelle étape ne consistera pas en une simple progression par extrapolation des indicateurs habituels de l’expérience numérique (c’est-à-dire « accélérer et réduire la latence »), mais visera plutôt à offrir à l’« application » un éventail beaucoup plus large d’options pour arbitrer les compromis liés à sa mise à disposition, afin d’adapter l’expérience aux exigences du consommateur numérique dans le contexte du cas d’usage concerné.

Du point de vue d’un technologue, les exigences métier impliquent que la diversification croissante des attentes en matière d’expérience d’utilisation nécessitera de concevoir un dispositif suffisamment souple et adaptable pour arbitrer, définir et optimiser les indicateurs courants de fourniture des applications : latence, bande passante, fiabilité et disponibilité. Par exemple, un système de réalité augmentée peut nécessiter une très faible latence et une bande passante élevée, tout en tolérant davantage la perte d’une petite partie du trafic réseau. À l’inverse, une caméra domestique utilisée dans le cadre d’un système d’alarme peut nécessiter une bande passante élevée, mais tolérer une latence (relativement) plus longue, de l’ordre de quelques secondes. Un compteur intelligent peut tolérer à la fois une latence élevée et une faible bande passante, mais exiger à terme un haut niveau de fiabilité, même si celui-ci n’est pas immédiat, afin que toute la consommation d’énergie soit enregistrée.

La conception et l’architecture d’un système suffisamment flexible et adaptatif pour répondre aux besoins de cette nouvelle étape de la « numérisation » nécessiteront un mécanisme permettant de répartir facilement les nombreux composants assurant la fourniture d’une expérience numérique entre différents emplacements du parcours de livraison des applications, et de les migrer si nécessaire. La répartition de ces composants applicatifs devra être adaptée aux impératifs de livraison — latence, bande passante, fiabilité — dictés par les exigences liées à l’expérience utilisateur, et les systèmes devront s’adapter en permanence à l’évolution de l’environnement et de la charge. Enfin, les enjeux de sécurité de l’application — gestion des identités, protection contre les logiciels malveillants, détection des intrusions — devront suivre de manière transparente les composants applicatifs à mesure qu’ils se déplacent au sein du parcours de livraison des applications.

S’engager résolument sur la voie à suivre

Alors, plus concrètement, qu’est-ce que cela signifie par rapport à notre situation actuelle ? Cela signifie ceci :

• Tout d’abord, puisque la majorité des consommateurs d’expériences numériques seront d’autres applications et services numériques, les API et leur gestion occuperont une place encore plus centrale.
• Deuxièmement, les emplacements de déploiement d’applications dont nous disposons aujourd’hui — le centre de données, le cloud et les services fournis depuis le cloud — ne suffiront pas à répondre aux besoins futurs. Plus précisément, pour offrir des expériences client plus riches, nous devrons être en mesure de rapprocher certains aspects de l’expérience applicative numérique de l’utilisateur final, en recourant à des technologies telles que la périphérie intelligente, les services de contenu et de calcul intégrés au chemin de distribution, ainsi que le SD-WAN sur ce même chemin. Nous devrons peut-être même étendre le chemin de distribution des applications afin d’utiliser des technologies de bac à sable côté client.
• Troisièmement, la périphérie constituera de plus en plus le point d’« entrée » dans la fourniture de l’expérience numérique et gagnera donc en importance en tant que principal point d’orchestration de cette fourniture.
• Enfin, en matière de sécurité, celle-ci doit non seulement être intégrée dès la conception et omniprésente, mais aussi fonctionner indépendamment de la manière dont les composants applicatifs sont répartis tout au long du parcours de livraison des applications.

Ces trois derniers sujets seront au cœur des prochains articles de cette série, dans lesquels nous parlerons de l’« Edge » et de son évolution, puis de ce à quoi ressemble une approche de la sécurité véritablement indépendante de la localisation.

À propos de l’auteur

Ken Arora

Autres articles de Ken Arora