L'agence nationale de la sécurité des SI sort enfin du bois ! Ses recommandations en matière de GenAI étaient attendues. Pas de surprise, mais un ensemble pertinent, à garder en tête.
Imaginer, construire, vendre, opérer une plateforme : c'est le seul moyen d'industrialiser la production des produits IT, et c'est donc un enjeu essentiel de 2023.
Les fabricants du SI : des rôles mieux cadrés
Le CTO est l’interlocuteur privilégié du CEO pour les aspects IT
Le rôle de CTO est relativement nouveau dans les entreprises. En l’absence de définition universelle de son poste, et vu que la technologie évolue constamment, l'étendue des fonctions du ou de la CTO évolue aussi en permanence.
On peut dégager deux éléments qui doivent caractériser ce rôle :
Le ou la CTO fait partie de l'organe de gouvernance de l'entreprise (ComEx, Comité exécutif...). C'est un C-Level.
Il/elle possède une forte expertise technologique dans plusieurs domaines.
Dans une start-up, le CTO est un allié du CEO, qui va créer toute la partie technique et faire grandir ses équipes. Lorsque l’entreprise grossit, le CTO peut prendre du recul, donner les directives, résoudre les problèmes épineux. Et toujours discuter business avec le CEO.
La croissance de l’entreprise verra arriver un Chief Product Officer, pour guider aux destinées des produits. Le CTO prendra le plus souvent la direction technique de la plateforme, ou bien la laissera aux bons soins de son CTO Office ; lui sera alors l’égérie technique de l’entreprise - et toujours l’interlocuteur privilégié du CEO sur la manière de bénéficier des capacités IT pour le business.
Le CIO s’assure de la bonne marche de l’entreprise
Alors que le CTO travaille sur les assets technologiques permettant d’offrir des produits de qualité aux clients, le CIO s’assure que les collaborateurs peuvent travailler efficacement. Il planifie, définit, sécurise et supervise le SI interne, qui permettent aux processus de l’entreprise de fonctionner correctement.
Traditionnellement, le CIO gère les fournisseurs et les achats, les équipes d’intégration et de support, ainsi que la réalisation de certaines applications spécifiques. Dans une entreprise moderne, le CIO sera en quelque sorte le CTO du SI, la personne qui construit à destination de ses clients internes un SI moderne, compatible avec le futur.
Le VP Engineering gère les équipes
La personne qui gère la réalisation d’un produit ou d’une plateforme ne devrait pas être le manager hiérarchique des équipes de développement : les intérêts d’un patron de produit, CPO ou CTO, et ceux d’un développeur peuvent considérablement diverger. La carrière du développeur sera davantage considérée par un manager détaché de l’opérationnel.
C’est pourquoi la fonction de VP Engineering prend corps aujourd’hui : il s’agit de recruter, accompagner, former des équipes pluridisciplinaires, faire en sorte qu’elles grandissent et s’épanouissent, se forment sur d'autres technologies, et aient envie de mettre à profit leurs nouvelles compétences au service de l’entreprise.
La plateforme développeur : optimiser l'infrastructure, la livraison des applications et l'expérience des développeurs
Dans le monde du développement logiciel, le succès de la création d'un produit repose sur l'efficacité des outils manipulés pour le construire et le déployer. On cherche toujours à réduire les frictions entre les équipes de développement et les infrastructures complexes, et les développeurs trouvent continuellement des pratiques modernes pour rendre l'ensemble du cycle de développement plus efficace.
Par exemple Microsoft, via ses solutions Github, consacre beaucoup d'énergie à la modernisation de ses outils pour répondre à la demande d'amélioration de la livraison des applications. Sa solution Copilot récemment publiée est conçue pour améliorer l'efficacité du développeur. Dans ce domaine, les autres acteurs ne sont pas en reste. Par exemple, Google travaille sur le projet Pitchfork et Jetbrain sur Fleet.
Dans le même temps, l'émergence des plateformes NoCode a créé une opportunité pour les entreprises de prototyper et de lancer rapidement des applications sans avoir à mettre en place une équipe entière d'ingénierie logicielle. Ces plateformes offrent des cycles de développement plus efficaces, car les développeurs peuvent déployer rapidement des applications avec un code minimal. En outre, ces plateformes réduisent le coût de prototypage. A terme, ces plateformes vont nous permettre de nous approcher du rêve de faire de chaque salarié un "citizen developer".
De leur côté, les développeurs bénéficient de véritables plateformes intégrant toute la chaîne CI/CD (intégration continue, déploiement continu) pour industrialiser les déploiements. Des outils tels que Github Actions, Gitlab ou Azure DevOps permettent aux développeurs de configurer et de gérer plus facilement des déploiements complexes avec un minimum d'efforts. Le but est de fiabiliser et d’atteindre un certain niveau de reproductibilité.
En outre, ces outils contribuent à créer des environnements plus sécurisés et une meilleure évolutivité, permettant de lancer les applications plus rapidement et avec moins de problèmes. Et vu que les développeurs commencent à être jugés aussi sur les aspects GreenIT de ce qu’ils produisent, nous devrions voir arriver sous peu ce type de métrique “carbon footprint driven” (pour reprendre un vocable de Gitlab) et des aides au code prenant en compte cet aspect.
Pour améliorer la sécurité, les postes de travail des développeurs deviendront des terminaux passifs, où seule la partie interface homme-machine de l'environnement de développement sera présente sur le poste de travail. La partie métier de l'environnement de développement sera sur un serveur. Cela permettra de mettre en place la notion de Zero Trust sur le poste de travail des développeurs, car le code produit ne sera plus directement sur le poste de travail. Cela renforcera la sécurité en limitant l'accès aux données sensibles (voir Amazon CodeCatalyst, Google Cloud Workstation).
En résumé, le paysage des plateformes de développement évolue rapidement, et les entreprises investissent massivement dans l'optimisation de l'infrastructure, de la livraison des applications et de l'expérience des développeurs. Grâce à l'utilisation de pratiques modernes, de services cloud améliorés, de plateformes no-code et d'une automatisation avancée, les entreprises sont en mesure de réduire la complexité, de diminuer le temps de déploiement, d'améliorer la sécurité et l'évolutivité et de permettre des pratiques de développement plus cohérentes. Avec les bons outils et stratégies en place, les équipes de développement peuvent créer, déployer et gérer des applications complexes plus efficacement et plus rapidement.
L'émergence des Citizen Developers permise par le low-code / no-code
Un Citizen Developer (développeur citoyen) est un terme utilisé pour décrire un développeur de logiciels non professionnel qui crée des applications pour son entreprise. Il peut s'agir de quelqu'un qui travaille dans un rôle non technique, mais qui possède les compétences et les connaissances pour créer des applications personnalisées en utilisant des plateformes de développement low-code ou no-code. Ces plateformes fournissent des composants et des outils pré-construits qui permettent aux utilisateurs de créer facilement des applications sans avoir besoin de connaissances approfondies en programmation. Cela permet aux personnes sans formation en développement de logiciels de créer des applications personnalisées qui peuvent aider à rationaliser les processus d'entreprise et à améliorer l'efficacité.
Bien que les Citizen Developers puissent créer des applications utiles pour leur organisation, ils ne vont pas remplacer les développeurs professionnels. Les Citizen Developers vont créer des applications de base, tandis que les développeurs professionnels vont continuer à développer les produits critiques au système d'information. Les choses risquent en revanche de devenir problématiques si les applications ainsi créées deviennent critiques (eu égard aux processus traités, aux données utilisées, au nombre ou à la nature des utilisateurs…) ; ce qui conduit nombre d’entreprises à considérer ce phénomène comme du “shadow IT”, à éliminer, donc.
Plutôt que de lutter contre l'arrivée des Citizen Developers, les entreprises devraient bien au contraire favoriser leur émergence en ouvrant très largement l'accès aux outils no-code / low-code tout en mettant en place un cadre de gouvernance et en fournissant des guides qui permettront d'encadrer ses pratiques.
Les années 2010 ont vu un changement important dans la façon dont les systèmes d'information étaient conçus et construits. Les méthodologies agiles et le craftsmanship sont devenus la norme, l'accent a été mis sur la livraison de logiciels itératifs et de haute qualité. Ce changement a marginalisé le rôle de l'architecte, qui était souvent considéré comme un obstacle au développement rapide favorisé par les équipes agiles.
Cependant, la complexité croissante de la technologie, la prolifération des appareils connectés et l'essor du cloud ont rendu l'expertise de l'architecte plus précieuse que jamais. Alors que les systèmes d'information sont de plus en plus distribués et interconnectés, l'architecte occupe une position unique pour s'assurer que les différents composants du système fonctionnent ensemble de manière transparente.
En outre, avec l'essor des API, des architectures pilotées par les événements et des microservices, il est plus important que jamais de considérer un système d'information comme un ensemble cohérent de produits, plutôt que comme une collection de composants isolés. L'architecte est chargé de concevoir et de mettre en œuvre la structure globale du système, en veillant à ce qu'il soit évolutif, maintenable et capable de s'adapter à l'évolution des besoins de l'entreprise.
L'importance des données a également augmenté ces dernières années, les organisations collectant et analysant de grandes quantités d'informations pour réaliser des analyses, des projections, et prendre de meilleures décisions. L'architecte est responsable de la conception de l'architecture des données, y compris le stockage, l'accès et la sécurité des données.
La sécurité et la conformité sont également devenues des préoccupations essentielles, avec l'augmentation des cybermenaces et la sévérité croissante des réglementations sur la protection des données. L'architecte doit s'assurer que le système d'information est sécurisé, à la fois contre les menaces externes et contre les accès non autorisés par les utilisateurs internes.
En bref, la complexité et l'interconnexion des systèmes d'information modernes ont rendu l'expertise de l'architecte plus précieuse que jamais. Alors que les organisations s'efforcent de construire des systèmes évolutifs, sécurisés et capables de s'adapter aux besoins changeants de l'entreprise, l'architecte est de nouveau au centre du jeu.
Un système d'information moderne est le modèle numérique de l'état d'une entreprise. Il peut être utilisé pour représenter les activités, produits, ressources, fonctions et transactions de l'entreprise. Ce modèle numérique permet aux utilisateurs de se faire facilement une idée des opérations de l'entreprise. En collectant, analysant et mettant à jour les données relatives aux différents aspects de l'entreprise, le modèle numérique peut être utilisé pour identifier les tendances, repérer les faiblesses et les opportunités, surveiller la production et les activités en aval et fournir une image globale des performances de l'entreprise. En outre, ce modèle numérique peut être utilisé pour prévoir les évolutions futures de l'état de l'entreprise, ce qui permet à l'entreprise de planifier plus efficacement et de réagir rapidement aux conditions changeantes du marché.
Les SI doivent être modernes, agiles, sécurisés et axés sur les données. La nécessité de ces caractéristiques entraîne l'adoption du Zero Trust Network (ZTN), du Cloud Native, de l'automatisation, des API et de l'architecture pilotée par les événements (EDA, event-driven architecture).
En mettant en œuvre ZTN, le Cloud Native, l'automatisation, les API et l'EDA, les SI peuvent passer de systèmes statiques, complexes et peu fiables à des systèmes d'information hautement sécurisés, dynamiques, fiables et évolutifs. Les entreprises s'orientent déjà vers la mise en œuvre de ces systèmes avancés dans le but de rester compétitives et de garantir la sécurité des données. Grâce à ces technologies qui sous-tendent les systèmes d'information du futur, les entreprises continueront à rester à la pointe des avancées technologiques et de la sécurité des données.
Zero Trust Network : sécurité et flexibilité
Le modèle Zero Trust Network prend pour principe que le réseau de l'entreprise ne doit pas être un élément considéré comme sécurisé. Cette approche permet de s'assurer que toutes les demandes d'accès à des applications où des données doivent être vérifiées, que ce soit au sein d'une organisation, d'un partenaire ou d'un client : ce n'est pas parce qu'un utilisateur / une machine est connecté(e) au réseau de l'entreprise qu'il/elle doit être considéré(e) comme fiable.
Le concept de sécurité périmétrique est réduit à son minimum, le cluster de machines. L'hypothèse de base est de dire que le réseau de l'entreprise est aussi sécurisé qu'internet. Certaines entreprises vont même jusqu'à dire que le réseau de l'entreprise est internet. Ce postulat, très puissant, permet aux entreprises qui l'adoptent de complètement se délester des coûts de mise en œuvre de l'infrastructure réseau et amène une très grande flexibilité pour mettre en œuvre un modèle d’entreprise plateforme, au centre de son écosystème, ainsi que des solutions qui permettront aux salariés de rester connectés en permanence au SI.
L'adoption d'une stratégie Cloud Native allège la tâche des services informatiques (moins de couches basses et de maintenance à gérer) et simplifie le développement d'applications résilientes, agiles et élastiques.
Un SI Cloud Native mixe des applications SaaS et des services managés avec des applications ou micro-services maison conteneurisés, déployés dans le cloud de son choix. Ce modèle offre une fiabilité, une évolutivité et une agilité constantes. Avec l'automatisation, les tâches sont souvent accomplies plus rapidement et avec plus de précision en déchargeant les équipes informatiques des tâches banales et sujettes aux erreurs. Les opérations d’administration, de maintenance et de sauvegarde sont prises en charge par la plateforme, les équipes pouvant se concentrer sur l’orchestration.
En l’absence d’une offre SaaS, la question qui se pose le plus souvent est de savoir si pour tel ou tel service il vaut mieux partir sur du service managé ou de la conteneurisation. Les deux approches sont parfaitement valables, et peuvent être mixées en fonction des workloads considérés. En adoptant les services managés, les entreprises créent une certaine adhérence au fournisseur, mais gagnent énormément sur le déploiement et la maintenance, libérant ainsi du temps et des ressources. En conteneurisant, les entreprises réduisent l'adhérence de leur workload à un cloud provider. C'est essentiel. La relation présente avec un fournisseur n'augure jamais de la relation future. En réduisant son adhérence à un fournisseur de cloud, l'entreprise s'achète la liberté future.
SASE et SD-WAN, pour penser le réseau étendu dans une perspective Cloud
Le Cloud, l’hybridation avec le “on premises” et le multicloud devenant la norme, il faut revoir la façon dont on utilise les ressources réseaux. Les collaborateurs doivent pouvoir accéder aux différentes composantes du SI de façon transparente, qu’il s’agisse d’applicatifs au sein d’un datacenter maison ou d’applications SaaS, et qu’ils soient au siège, en agence, sur le terrain ou chez eux.
Plutôt que penser liaisons louées, MPLS et VPN, il s’agit donc de repenser le réseau étendu dans une perspective Cloud, un concept auquel Gartner a donné le nom de Secure Access Service Edge, ou SASE (prononcer sassy). Dans une architecture SASE, les services Cloud gèrent l’authentification et plus largement toute la sécurité du réseau, et une couche d’abstraction logicielle permet de gérer l’infrastructure réseau : le SD-WAN, software-defined wide area network. Les services de SD-WAN permettent d’agréger plusieurs types d’infrastructures d’un ou plusieurs fournisseurs (MPLS, fibre, SDSL, 4G…) et de gérer ainsi des réseaux complexes de manière centralisée, industrialisée et simple.
API : les clés du SI
Les API sont essentielles au succès des systèmes d'information. Elles permettent l'intégration de systèmes et d'applications disparates. Cela simplifie la façon dont les systèmes numériques au sens large communiquent et échangent des données. Les API aident à automatiser l'accès aux SI et facilitent l'ouverture sécurisée du système d'information.
L’APIsation d’un système le rend évidemment plus agile, pour des usages internes, mais aussi plus ouvert sur l’extérieur, pour intégrer des composants externes et des partenaires. C’est la clé d’une entreprise plateforme, typiquement.
Un exemple intéressant est celui de la startup Patch qui se positionne sur la distribution des droits carbone, et s’intègre via son API. Grâce à la plateforme de Patch, les entreprises de toutes tailles, quel que soit leur budget, peuvent facilement acheter des crédits carbone en tant que moyen d'agir pour le climat. L'infrastructure transparente de Patch transforme un système traditionnellement complexe et opaque pour l'achat de crédits carbone. Patch fournit également aux développeurs de solutions climatiques l'infrastructure dont ils ont besoin pour développer et développer leurs entreprises, facilitant ainsi des transactions importantes sur le marché du carbone volontaire. Patch a levé 55 millions en Série B en Septembre 2022.
Event Driven Architecture : souplesse et réactivité
L'architecture pilotée par les événements (Event Driven Architecture - EDA) permet de développer des applications qui répondent en temps réel sans avoir à interroger continuellement le système pour obtenir de nouvelles informations. Cette architecture permet la surveillance d'événements métier qui peuvent déclencher des processus réactifs ; on parle donc aussi d’architecture réactive.
Plusieurs outils de type pub/sub (publish & subscribe, comme Google pub/sub ou AWS Kinesis) proposent un mécanisme simple, assurant la distribution de la donnée, tandis que des plateformes spécifiques proposent un environnement complet, incluant la possibilité de conserver les données transmises, voire les traiter ou en assurer la gouvernance. Dans ce domaine, l’implémentation de Kafka prend de l’ampleur, qu’il s’agisse de la technologie open source ou d’offres managées comme celle de Confluent.
De ce fait, les outils et plateformes de diffusion d’événements au fil de l’eau ont une large palette d’utilisation, de la simple ingestion de données d’un outil transactionnel ou d’un capteur IoT vers une base ou une autre application (pour déclencher un processus, éditer une facture, etc.), par exemple, à du traitement complexe en temps réel, avec persistance des données à des fins d’audit ou de constitution d’un modèle de machine learning.
Ce type d'architecture peut contribuer à offrir de meilleures expériences aux utilisateurs tout en économisant le temps et les ressources associés à l'interrogation et à l'extraction de données. Elle offre également plus de souplesse au SI en favorisant le découplage entre des applications qui émettent ou consomment des événements, et donc davantage de résilience. Les processus du SI ne sont plus figés, ils sont chorégraphiés.
SLSA : pour sécuriser la chaîne de production logicielle
La sécurité de la “supply chain” logicielle devient un sujet de préoccupation, avec l’apparition de frameworks tels que SLSA (Supply chain Levels for Software Artifacts, à prononcer salsa). L’idée est d'assurer l'intégrité des binaires de bout en bout et en s'inspirant des pratiques internes de grands acteurs du logiciel comme Google. C'est un ensemble de bonnes pratiques incrémentales permettant d'atteindre des niveaux de sécurité de plus en plus élevés.
Des outils open source ont fait leur apparition, tels que Sigstore, permettant d'implémenter SLSA et facilitant la signatures des binaires et de leur vérification ; les travaux de l’OpenSSF (Open Source Security Foundation) sont à suivre de près. En bout de chaîne, la vérification des binaires au déploiement deviendra la norme ; on retrouve par exemple « Binary Authorization » sur Google Cloud ou Kyverno en open source.
MACH est un acronyme qui signifie Microservices, API-first, Cloud native et Headless. L’utilisation conjointe de ces approches est une tendance technologique qui a gagné en popularité ces dernières années et qui devrait continuer à gagner en importance en 2023 et au-delà.
Les microservices font référence à une architecture logicielle où l'application est construite comme une collection de petits services indépendants, plutôt que comme une base de code monolithique. Cette approche permet une plus grande flexibilité et évolutivité, car chaque service peut être développé et déployé indépendamment, et de nouveaux services peuvent être ajoutés ou supprimés selon les besoins. En revanche, cela introduit aussi de la complexité, il est donc important de bien cadrer et gouverner cette approche, en gardant en tête que l’important est surtout de modulariser l’applicatif. Le M de MACH pourrait ainsi se lire comme “Modules-based”.
API-first signifie que l'application est conçue et construite autour des API, qu'elles soient REST ou GraphQL. Cette approche met l'accent sur les API comme principal moyen d'accéder et d'interagir avec l'application, plutôt que sur l'interface utilisateur.
Cloud native fait référence aux applications qui sont conçues et construites pour fonctionner nativement dans le cloud. Cela signifie qu'elles sont construites à l'aide de technologies de type containers, serverless (fonctions déclenchables avec des événements, sans se soucier de la plateforme sous-jacente) ou autre capacités PaaS (Platform as a service) et qu'elles sont optimisées pour l'environnement cloud, ce qui les rend évolutives, résilientes et faciles à déployer et à gérer.
Headless signifie que l'application n'a pas d'interface utilisateur, et qu'on y accède et la contrôle exclusivement par le biais d'API. Cette approche permet une plus grande flexibilité et personnalisation, car l'interface utilisateur peut être construite et modifiée indépendamment de l'application sous-jacente.
Dans l'ensemble, la tendance technologique MACH est axée sur la création d'applications flexibles, évolutives et natives dans le cloud, utilisant les API comme principal moyen d'accéder à l'application et d'interagir avec elle. Cette approche permet une plus grande agilité et innovation, et est bien adaptée aux besoins des entreprises modernes.
REST vs GraphQL, les deux options vont trouver leur place
GraphQL et REST sont tous deux des styles architecturaux pour la création d'API, mais ils présentent quelques différences essentielles. REST (Representational State Transfer) est une conception bien établie pour construire des API Web qui existe depuis longtemps, tandis que GraphQL est une technologie plus récente développée par Facebook pour pallier les limites rencontrées avec REST. REST demande en effet de créer différents points d’accès (endpoints) selon les données que le producteur d’API va mettre à disposition, tandis qu’en GraphQL, un seul point d’accès permet d’accéder à l’ensemble de la donnée, et c’est le consommateur qui choisira celle qu’il souhaite récupérer.
Une autre différence est la façon dont les erreurs et la validation des données sont gérées. Dans une API REST, le serveur renvoie généralement des codes d'erreur HTTP pour indiquer les échecs, comme 404 pour "non trouvé" ou 500 pour "erreur de serveur". Dans une API GraphQL, le serveur peut renvoyer des messages d'erreur détaillés avec les données, ce qui facilite la gestion et le débogage des problèmes par le client.
Dans l'ensemble, le choix entre l'utilisation d'une API GraphQL ou REST dépend des besoins et exigences spécifiques du projet. GraphQL peut être un bon choix pour construire des API qui doivent être flexibles et personnalisables, tandis que REST peut être un bon choix pour les API qui suivent un design plus standard et établi.
Les webhooks sont un moyen pour une application de fournir à d'autres applications des informations en temps réel. Ils sont une brique importante des architectures pilotées par les événements, ce qui signifie qu'ils permettent à différentes applications de communiquer entre elles en envoyant et en recevant des notifications lorsque certains événements se produisent. Les Webhooks sont souvent utilisés pour fournir à d'autres applications des mises à jour en temps réel, par exemple lorsqu'un nouvel utilisateur s'inscrit à un service, lorsqu'une entité métier change d'état, lorsqu'une nouvelle donnée entre dans un système.
Les webhooks sont fondamentaux dans EDA (Event Driven Architecture) car ils offrent un moyen pour différentes applications de communiquer entre elles en temps réel. Cela permet de créer des systèmes d'information plus dynamiques et plus réactifs, où les changements dans une partie du système peuvent être immédiatement répercutés dans d'autres parties du système.
Les webhooks sont aussi un choix naturel pour construire un système d'information en tant qu'ensemble de produits car ils permettent à différents produits de communiquer entre eux et de partager des informations en étant faiblement couplé.
L'adoption des webhooks a augmenté ces dernières années, car de plus en plus d'entreprises ont commencé à utiliser une architecture pilotée par les événements dans leurs systèmes d'information.Ils sont désormais couramment utilisés, et leur adoption va continuer de croître.
Le serverless et ses déclinaisons de fonctions "as a service" sont très populaires. Ceci permet aux développeurs de se concentrer sur les aspects essentiels de leurs applications, leur permettant de créer des applications fiables, évolutives, hautement disponibles et tolérantes aux pannes, avec des délais de mise en production courts.
Data-Oriented Programming : la donnée au cœur du développement
Le programmation orientée données (data-oriented programming) est un paradigme de programmation qui se concentre sur la manipulation des données et sur la façon dont elles traversent un programme.
En contraste, la programmation orientée objet (OOP) est un paradigme de programmation qui se concentre sur le concept d'objets, qui sont des structures de données qui contiennent à la fois des données et des fonctions qui opèrent sur ces données. Les langages OOP permettent généralement aux objets d'interagir les uns avec les autres à l'aide de l'héritage et d'autres mécanismes.
La programmation fonctionnelle, quant à elle, est un paradigme de programmation basé sur l'idée de fonctions mathématiques. En programmation fonctionnelle, les fonctions sont des citoyens de premier ordre, ce qui signifie qu'elles peuvent être traitées comme tout autre type de données et peuvent être passées en arguments à d'autres fonctions ou retournées en tant que résultats de fonctions.
Une différence clé entre la programmation orientée données et ces autres paradigmes est que la programmation orientée données se concentre sur l'organisation et la manipulation des données, tandis que OOP et la programmation fonctionnelle se concentrent davantage sur les opérations effectuées sur ces données. En d'autres termes, la programmation orientée données s'intéresse au "quoi" d'un programme, tandis que OOP et la programmation fonctionnelle sont plus préoccupées par le "comment". Cette nouvelle tendance trouve ses racines dans le fait que le système d'information est de moins en moins considéré comme étant un lieu de stockage de l'information mais de plus en plus comme un outil de traitement des flux d'informations.
L’adoption des Progressive Web Apps (PWA) continue à progresser. Elles sont considérées comme faisant partie de l'avenir pour plusieurs raisons :
Les PWA offrent une expérience utilisateur similaire à celle des applications natives, avec des fonctionnalités telles que la navigation hors connexion, les notifications push et l'accès aux fonctionnalités du périphérique (appareil photo, capteur de localisation, etc.). Cela permet aux utilisateurs d'interagir avec les PWA de manière fluide et intuitive, sans avoir à passer par les magasins d'applications.
Les PWA sont plus faciles et moins coûteuses à développer et à maintenir que les applications natives. Elles sont basées sur des technologies web standard, ce qui signifie qu'un développeur peut créer une PWA en utilisant les compétences et les outils qu'il maîtrise déjà, sans avoir à apprendre de nouvelles technologies spécifiques aux plateformes mobiles.
Les PWA peuvent être découvertes et installées facilement par les utilisateurs grâce aux moteurs de recherche et aux liens partagés sur les réseaux sociaux. Elles ne nécessitent pas de téléchargement depuis un store, ce qui signifie qu'elles peuvent être accessibles à une audience plus large. Ceci permet aussi de s'affranchir de la taxe des stores lorsque ces applications offrent des services payants.
En résumé, même si certains cas d’usage ne leur conviennent pas, les PWA offrent une expérience utilisateur riche, sont faciles à développer et à maintenir, sont accessibles à une audience large et sont adaptables aux différents écrans. Ces avantages en font un choix de plus en plus populaire pour les entreprises qui souhaitent développer une présence mobile.
Dark mode, une option pour l’expérience utilisateur
Le mode sombre (ou dark mode) est une option de design qui permet aux utilisateurs d'afficher les interfaces d'une application web ou mobile avec des couleurs sombres au lieu des couleurs claires habituelles. Cela peut inclure un fond noir ou gris foncé, avec du texte et des éléments d'interface en couleurs claires.
Les entreprises doivent proposer le mode sombre pour plusieurs raisons :
Le mode sombre peut améliorer l'expérience utilisateur en offrant une interface plus soignée et plus professionnelle. Les couleurs sombres sont souvent perçues comme plus élégantes et plus esthétiques que les couleurs claires, ce qui peut renforcer l'attrait d'une application ou d'un site web.
Le mode sombre peut aider les utilisateurs à réduire la fatigue oculaire et à prévenir les maux de tête lorsqu'ils utilisent l'application pendant de longues périodes. Cela peut améliorer la satisfaction des utilisateurs et leur fidélité à l'application.
Le mode sombre peut aider à économiser la batterie de l'appareil (si ce dernier ne gère pas automatiquement sa luminosité). Les écrans OLED utilisent moins d'énergie pour afficher des couleurs sombres que des couleurs claires, ce qui signifie que l'utilisation du mode sombre peut prolonger la durée de vie de la batterie.
WebAssembly dope les performances des applications Web
Technologie portable (pas de problème de cross-compilation), rapide (proche du code machine) et sécurisée (sandbox), WebAssembly (Wasm) commence à percer. Il s'agit d'une solution permettant d'exécuter du code bas niveau directement dans le navigateur, offrant des améliorations spectaculaires des performances. C'est une solution pour l'exécution, dans le navigateur, d'applications écrites en C++, Rust ou Go.
WebAssembly est très intéressant car cette technologie permet aux applications diffusées via le Web d'égaler la vitesse des applications natives. Par exemple, les jeux vidéo, les applications de réalité virtuelle et augmentée et d'autres applications gourmandes en ressources qui étaient traditionnellement confinées aux applications desktops peuvent désormais être déployées sur n'importe quel appareil doté d'un navigateur Web moderne. Les plateformes mobiles en particulier profitent de WebAssembly par la faible consommation d'énergie des applications Wasm.
WebAssembly va aussi bien au-delà du navigateur. Cette technologie peut aussi être utilisée dans les applications de cloud computing et d'Internet des objets (IoT) : WebAssembly fournit un environnement de sandboxing sécurisé dans lequel le code peut s'exécuter sans avoir d'impact sur les autres programmes. Cela permet de déployer des apps en minimisant l'impact des vulnérabilités des tiers.
En résumé, WebAssembly offre des améliorations de performances et un environnement “sandboxé” pour exécuter du code en toute sécurité. Ces avantages en font une technologie à suivre.
Angular, Vue.js, React.js, Svelte et Solid.js sont tous des frameworks JavaScript populaires pour le développement front-end. Ils sont tous open source et gratuits à utiliser, et chacun d'entre eux a ses propres forces et faiblesses.
Angular est un framework complet qui permet aux développeurs de créer des applications web complexes et puissantes. Il est développé et maintenu par Google, et est largement utilisé dans les applications d'entreprise.
Vue.js est un framework plus léger et flexible, et convient bien pour la création d'interfaces utilisateur et d'applications de type SPA (Single Page Application). Il est relativement facile à apprendre et à utiliser, et il a une forte communauté de supporters et de contributeurs.
React.js est un autre framework populaire pour la création d'interfaces utilisateur. Il est développé et maintenu par Facebook, et est utilisé par de nombreuses grandes entreprises pour construire leurs applications web.
Svelte.js met l’accent sur la vitesse de chargement, puisque le code est compilé et n’embarque donc pas de runtime. Plusieurs tests l’ont distingué comme plus performant que Vue et React.
Solid.js est un framework relativement nouveau qui gagne en popularité parmi les développeurs web. Il est construit sur les idées des frameworks Svelte et React, et permet aux développeurs de créer des applications web performantes avec un minimum de code. C'est sans doute le framework javascript qui a actuellement le plus de traction pour développer les couches front end des applications.
En termes de popularité, il est difficile de dire quel est le framework le plus populaire, car cela peut varier en fonction du contexte et de l'audience. Cependant, selon les données les plus récentes de l'enquête State of JavaScript, Solid.js est le plus populaire parmi les développeurs professionnels, suivi par React, Vue.js et Angular.
Back
Next.js, Nest, SvelteKit et Nuxt sont tous des frameworks pour construire des applications server-rendered en utilisant JavaScript. Ils offrent tous une manière simple de démarrer un nouveau projet.
Next.js est construit sur React, Nest utilise TypeScript et est conçu pour construire des applications côté serveur efficaces et évolutives, SvelteKit est basé sur le framework de composants Svelte, et Nuxt est destiné à la construction d'applications avec Vue.js.
Astro, en revanche, est un framework pour construire des applications server-rendered ou statically-exported en utilisant la bibliothèque de composants React.
Test
Jest, Cypress, Playwright et Mocha sont des frameworks de test JavaScript. Jest est populaire pour tester les applications React, tandis que Cypress est souvent utilisé pour tester les interactions bout à bout sur un site ou une application Web. Playwright est assez nouveau et se concentre sur les tests d'applications Web sur différents navigateurs. Mocha est un framework de test d'usage général qui peut être utilisé avec une variété d'outils différents.
Il est difficile de dire lequel de ces frameworks est le plus populaire, car cela peut varier en fonction de l'utilisation spécifique et des préférences du développeur individuel. Jest et Mocha sont probablement les plus utilisés, suivis de Cypress et Playwright.
Build
Vite.js, esbuild et webpack sont tous des outils de build JavaScript populaires. Ils ont chacun leurs propres caractéristiques et approches qui les rendent plus adaptés à différents types de projets et de cas d'utilisation.
Vite.js est un outil relativement nouveau et avec une courbe d'adoption rapide. Il s'attache à offrir une expérience de développement rapide et légère. Il utilise des fonctionnalités JavaScript modernes et une approche basée sur Rollup pour ne reconstruire que les parties de l'application qui ont été modifiées, ce qui le rend plus rapide que d'autres outils build.
Esbuild est aussi un outil relativement nouveau qui se concentre sur la vitesse. Il est connu pour sa capacité à traiter de grandes quantités de code JavaScript très rapidement, ce qui en fait un bon choix pour les applications javascript volumineuses.
Webpack est un outil historique, plus établi qui a été largement utilisé pour construire les applications front. Il est configurable et peut être étendu avec des plug-in pour ajouter des fonctionnalités supplémentaires. Il prend également en charge un large éventail de technologies, notamment TypeScript et JSX.
Cloud, la plateforme de choix
Le Cloud s’impose comme la plateforme de choix pour déployer rapidement des infrastructures sécurisées, en profitant des apports spécifiques de chaque cloud provider : technologies, services managés, présence dans certains pays, sourcing énergétique… Les SI deviennent de facto hybrides, et le plus souvent en mode multicloud.
Une Infra as Code pervasive et simplifiée
La meilleure façon de déployer et maintenir une infrastructure cloud est bien de la coder et de gérer ce code comme on le ferait avec du code applicatif. Cette notion d’IaC (infrastructure as code) est au cœur des architectures cloud-natives. C’est ce qui apporte la réactivité, mais aussi la sécurisation : le code peut être examiné et débuggé au moment du déploiement, pour assurer sa conformité à la “cloud policy” (politique de sécurité cloud) de l’entreprise.
Les outils d’automatisation de type Terraform sont indispensables dès lors qu’on souhaite industrialiser l’approche cloud. Dans ce cadre, le développement du projet CDK TF (Cloud Development Kit for Terraform), qui s’inspire de Pulumi (framework concurrent, et moins chanceux, de Terraform) est à suivre de près. Ce framework de l'écosystème Terraform, développé par HashiCorp, permet de décrire l'infrastructure désirée en utilisant un langage de programmation tel que TypeScript, Python ou Go plutôt que d'utiliser le DSL spécifique à Terraform (HCL).
Ce qui apporte plusieurs avantages :
Pas de DSL à apprendre pour les équipes découvrant l'IaC et possédant déjà des compétences dans un de ces langages.
Possibilité d'utiliser les constructions natives (idiomatiques) propres au langage utilisé.
Possibilité d'utiliser les mêmes outils et workflows de CI/CD que ceux utilisés pour la stack applicative.
Beaucoup plus de contrôle et de liberté en utilisant un langage impératif (python, go...) plutôt que déclaratif (HCL).
Interopérabilité bidirectionnelle entre le code "legacy" (HCL) et CDK TF.
Passerelle facilitée entre les populations dev et devops.
La création de plateformes et de produits dans le cloud est un investissement créant de la valeur pour l’entreprise. Après des décennies où l’IT était uniquement vue comme un centre de coûts, cette vision orientée produits rebat les cartes, d’autant qu’avec le cloud, il devient possible de connaître très précisément le coût de chaque service, à la seconde près. Et de le ventiler en fonction des produits business - dès lors qu’on aura bien pris la précaution de labelliser les ressources cloud.
Ce plan d’étiquetage des ressources est la pierre angulaire de la démarche FinOps, contraction d’opérations et de finances. Les responsables FinOps animent, orchestrent cette démarche, acculturent les utilisateurs (IT, métiers et financiers), diffusent les bonnes pratiques, et enfin rassemblent, extraient et préparent les données pour que :
L’IT puisse optimiser son usage, réduire son utilisation des ressources au strict nécessaire, avec des impacts positifs autant pour les finances que pour l’environnement.
Les directions puissent analyser les performances et prendre des décisions stratégiques pour l'entreprise.
Entre l’augmentation des dépenses prévisibles dans le cloud (davantage d’utilisateurs, périmètre élargi, ajout de fonctionnalités…) et la nécessité de contrôler ses investissements au vu d’une situation économique incertaine, le FinOps devrait venir tout en haut des préoccupations.
Des CC4E interagissant avec des équipes plus décentralisées
Le Cloud devient une plateforme mieux maîtrisée par les équipes centrales ; il est temps maintenant de diffuser plus largement le savoir et le savoir-faire cloud au sein des entreprises. Les CCoE, constitués sur le modèle de centre d’expertise pour les premiers déploiements, devraient ainsi se muer en CC4E, Cloud Centers For Excellence dans cette optique d’acculturation (cf. notre section #orga pour la mue des CoE en C4E).
De la même façon que les équipes doivent devenir plus autonomes pour être plus agiles et plus efficaces dans l’atteinte des objectifs stratégiques de l’entreprise, elles doivent aussi gagner en indépendance sur la technologie cloud - ce qui n’empêche nullement de fixer des règles et de pré-paramétrer des plateformes de référence au niveau du groupe.
Le cloud privé et déconnecté pour quelques cas d’usage
Les débats sur le cloud souverain et le cloud de confiance (cf. notre section #culture sur la souveraineté) ont mis en évidence des besoins, et finalement donné naissance à une nouvelle forme de cloud, où les hyperscalers deviennent fournisseurs d'infrastructures de cloud sans en assurer le run (par exemple S3NS, la co-entreprise managée par Thalès, qui s’appuie sur les technologies de Google Cloud).
Ces offres déconnectées du réseau principal du fournisseur de cloud, opérées par des entreprises françaises, constituent une solution intéressante au dilemme de certaines entreprises de type OIV souhaitant bénéficier de capacités du cloud telles que des services managés (et allant donc au-delà du simple hébergement de machines virtuelles).
Le cloud au cœur des questions d’environnement et de ressources énergétiques
Les notions de “sustainability”, d’impact carbone et d’approvisionnement énergétique deviennent cruciales (cf. aussi à ce sujet notre section #culture). Une récente enquête PAC/numeum indique que dans les trois quarts des appels d’offres, les fournisseurs du numérique doivent expliquer et démontrer leurs actions de type RSE.
A cela s’ajoute la nécessité d’assurer la résilience de son IT en cas de coupures de courant. Les fournisseurs de cloud ont anticipé ces problématiques et prennent les devants pour apporter des solutions concrètes.
Dans un monde de plus en plus hostile, le cloud est une des solutions pour augmenter le niveau minimum de sécurité des entreprises. D'une part parce que la sécurité est au cœur des préoccupations et des investissements des fournisseurs de cloud, c’est primordial pour leur business model.
D’autre part, parce que les offres de sécurité managées sur le cloud pallient le manque de talents en cybersécurité, en externalisant une partie de la stratégie de sécurité.
Enfin, parce que le poste du développeur reste une faiblesse dans le SI : un développeur est souvent administrateur de sa machine et est amené à y installer beaucoup de logiciels. La virtualisation des postes de travail des développeurs, sujet sur lequel planchent par exemple Google Cloud et AWS, devrait apporter un niveau de sécurité supplémentaire.
La sécurité “as code” devient obligatoire
La sécurité doit être prise en considération dès le démarrage du projet cloud : le fournisseur ne fait pas tout, nous sommes dans un “shared responsibility model”, un modèle où le fournisseur et le client partagent la responsabilité. Les fournisseurs de cloud fournissent des infrastructures et des outils, aux entreprises de bien les utiliser et de ne pas ouvrir leurs services à tous les vents.
Au-delà du respect des bonnes pratiques d'une architecture cloud sécurisée, cette attention à la sécurité devra se matérialiser sous forme de code. Tout comme une infrastructure cloud est scriptée (“infra as code, IaC”), la sécurité devient aussi “as code”.
On retrouve ainsi :
La politique de sécurité as code : l'ensemble des règles de sécurité communes à l'ensemble des projets de l'organisation, dont il ne sera pas possible de s'écarter. Par exemple, l’interdiction globale de rendre publique n'importe quel bucket appartenant à l'organisation (via Google Organization Policies, AWS Security Control Policies ou encore Azure Security Policies).
Les règles de configuration des ressources d’infrastructure cloud as code, qui inspectent les scripts IaC : ce sont les règles de bonne configuration de chaque produit cloud qui sont évaluées avant le déploiement et le stoppent si une non conformité a été détectée (exemples d’outils : Checkov, KICS, Spectral, tfsec…).
La détection de dérives (“drift”) par rapport aux configurations initiales, en cas de changements manuels.
Dans ce domaine, les travaux de la Cloud Native Computing Foundation sur OPA, Open Policy Agent, seront intéressants à suivre : OPA est un langage déclaratif permettant de spécifier une “policy as code” à appliquer dans les microservices, Kubernetes, pipelines CI/CD, etc.
Le domaine de l’intelligence artificielle évolue très rapidement, et on pourrait passer son temps à essayer de courir après les innovations. Il faut donc prendre du recul, considérer que c’est un domaine dont on ne peut prévoir les avancées mais qui existe, et surtout qui fournit un ensemble d’outils, dont certains sur étagère, sous forme de services, qui peuvent créer de la valeur pour l’entreprise (nouveaux business models, automatisation de processus, aide à la décision…).
Dès lors, trois grands challenges se posent :
Comment authentifier et détecter les fakes. Les progrès de l’IA ont rendu possible la création de photos et même de vidéos très convaincantes, soit de personnes n’existant pas, soit, encore plus problématique, de personnes existant vraiment. De fait, quand le compte DeepTomCruise sur TikTok réalise des vidéos où il se met en scène en tant que Tom Cruise, c’est très inoffensif ; quand la technique est utilisée pour montrer le président de l’Ukraine appelant ses concitoyens à déposer les armes face à la Russie, les conséquences peuvent être bien plus graves. D’où les efforts, à suivre de près, des fabricants de matériels et éditeurs de logiciels pour intégrer des outils destinés à marquer et authentifier les médias produits.
Créer des produits innovants et pertinents. L’IA est un domaine nouveau, protéiforme, survendu à certains, méconnu par d’autres, craint enfin par quelques-uns. Il y a donc un gros travail à faire sur le terrain, pour acculturer les collaborateurs, comprendre où et comment l’IA pourrait les aider, dans une démarche de type design thinking - incluant utilisateurs, data scientists et équipes IT. Une idéation collective permettra de s’approprier le sujet, et de valider les cas d’usage où l’IA pourra réellement apporter de la valeur.
Passer à l’échelle. La problématique principale de l’IA n’est pas d’imaginer un modèle qui fonctionne en théorie, c’est de pouvoir l’intégrer avec le système d’information et faire en sorte qu’il délivre véritablement de la valeur, en l’améliorant tout au long de son cycle de vie - c’est tout l’objet du MLOps (cf. notre section #Data).
