La percée du digital dans l’industrie automobile n’est plus aujourd’hui un simple concept, mais une réalité qui s’exprime à de très nombreux niveaux : recherche et développement, conception, etc.  Mais ce n’est pas tout, au-delà de ces éléments, le digital occupe aussi une place essentielle dans les concessions automobiles et fait évoluer leur organisation en leur permettant de moderniser leurs processus de gestion. En ce sens, on pense bien entendu aux formidables apports liés à l’utilisation de technologies comme les ERP et les DMS (dealer Management System) qui permettent de piloter efficacement les opérations courantes des concessions.

La mobilité, plus qu’un simple concept

L’un des principaux enjeux des concessions est d’offrir à leurs clients une qualité de service de premier plan à de nombreux niveaux. Dès lors, il convient que l’ensemble des services de la concession (commercial, technique, atelier, etc.) puissent moderniser leurs processus de gestion historiques pour fluidifier leurs opérations. À titre d’exemple, au niveau de l’accueil client et du service commercial, la mobilité permettra d’accéder à de nombreux bénéfices concrets et complémentaires.

Ainsi, l’un des grands enjeux de l’équipe commerciale est d’assurer un accueil et un on-boarding efficace des clients dès leur arrivée en concession. En ce sens, l’usage de la tablette offre une réelle opportunité de réaliser cette opération de manière simplifiée et en tout lieu dans la concession.

Il s’agit également d’offrir une image moderne au client et de créer un sentiment de qualité et de confiance dès l’arrivée au sein de la concession. Côté productivité, une telle démarche est aussi un réel avantage pour les équipes commerciales qui peuvent réduire les temps de prise en charge et d’enregistrement et fluidifier ainsi le traitement des arrivées notamment sur les plages horaires les plus chargées.

Nous pourrions aussi évoquer la révolution que vivent les équipes techniques et les mécaniciens dans les ateliers des différentes concessions automobiles. En effet, les bons d’interventions à effectuer sur les véhicules, les suivis d’activité et des actions entreprises, etc. qui étaient jusqu’alors réalisés sur papier sont aujourd’hui entièrement digitalisés. Ce faisant, les photos d’intervention et comptes rendus digitaux sont directement saisis depuis des tablettes et les informations automatiquement enregistrées dans le dossier client.

Se préparer aux nouveaux usages à venir

Sur ce point, de nombreux sujets émergent comme par exemple les données collectées et envoyées par le véhicule directement chez les concessionnaires. Dans un futur proche, les véhicules pourront ainsi transmettre des alertes et données au garage qui pourra de son côté, de manière proactive, proposer des services de maintenance ou de réparation, commander les pièces appropriées, organiser l’intervention et accueillir le client de manière ultra personnalisée. Ici encore la mobilité devra être gérée et prise en compte dans les systèmes de gestion des concessions.

Globalement, la mobilité doit donc permettre de saisir directement des informations de tous types afin de les intégrer au sein du système d’information des concessions. Les plateformes de DMS et les ERP peuvent alors être alimentées de précieuses données complémentaires (techniques, commerciales, financières…). De fait, la concession automobile pourra gagner en agilité dans la gestion de ses opérations quotidiennes. Rationalisation, qualité de service, meilleur confort de travail pour les équipes, suivi de premier plan et transparence pour les clients sont donc autant de bénéfices liés à l’usage de la  mobilité.

Par Cyril Trouiller, Directeur général de Porsche Informatik France 

Par Thibault Paul-Joseph, Responsable Commercial Channel chez ITS Integra

Les Services Managés à l’ère du Cloud public

L’infogérance classique, désigne l’ensemble des Services Managés mis à disposition des infrastructures, réseaux et Systèmes Informatiques. Les transformations opérées sur les méthodes de consommation de ces derniers imposent une adaptation des fournisseurs.

Bien évidemment, la fracture numérique continue à persister avec des entreprises qui démarrent à peine leur transformation. Mais le « gâteau » a tendance à se faire plus petit chaque année sur les couches traditionnelles. En migrant sa messagerie vers un service Office 365, Google Workspace ou autre, l’entreprise change radicalement de modèle. Cela lui permet également d’accéder à de nouvelles fonctionnalités. Elles passent d’un IaaS avec Services Managés, à une solution SaaS nécessitant une gestion continue sans gestes d’exploitation traditionnels.

Les ISV en tête de cortège

Les éditeurs ont chamboulé le marché en réduisant le fameux « TTM » (Time To Market), tout en adoptant un modèle de vente à la consommation réelle. Cela a permis une approche bien plus agile des opérations de mise à niveau des versions et de mise en production de nouvelles fonctionnalités à un rythme effréné. Parmi eux, nous retrouvons aussi bien des sociétés récentes, comme SalesForce, ou plus anciennes, comme Microsoft. En effet, certains acteurs historiques ont réussi à changer de cap en relativement peu de temps. N’oublions pas non plus les multiples éditeurs spécialisés « Cloud native » et les établis qui ont su s’aligner.

La généralisation des méthodologies Agile et Dev(Sec)Ops constitue une évolution majeure dans les entreprises. Avec une forte volonté de pouvoir garder la main sur les développements, ces dernières sont moins dépendantes d’un ensemble d’acteurs tiers (TMA, hébergeur, infogérant, etc.). Elles peuvent maintenir leur objectif : être le plus possible en phase avec les impératifs des métiers.

Le grand changement réside dans le fait d’offrir les services directement sur le Cloud public. Cela facilite grandement l’autonomie des éditeurs en comparaison avec un modèle « sur site ». Au cœur du dispositif, nous retrouvons l’exigence de pouvoir déployer et de mettre à niveau de manière continue. Autrement dit, la chaine CICD (Continuous Integration, Continuous Deployment). 

S’adapter en tant que spécialiste des Services Managés

Les acteurs des Services Managés doivent donc s’adapter au changement des approches et de l’environnement, tout en repensant une partie de leur offre de services. Comment accompagner à travers des services bien précis le client dans sa trajectoire ? Ces services doivent être à la fois personnalisés et reproductibles, c’est-à-dire industrialisables. D’un point de vue macro, cela ne change pas la mission historique de tout opérateur de Services Managés.

Il y a d’abord une dimension technologique à prendre en compte : conteneurisation et micro-services, divers logiciels de l’environnement développement et production, etc. Mais avant tout, il s’agit de connaître et comprendre les tenants et aboutissants du métier du client. Le métier du fournisseur de Services Managés vise à mitiger les risques, selon l’activité et les objectifs du client : sécurisation des données, disponibilité, continuité des services, etc. S’adapter est une nécessité mais ce n’est pas pour autant que les bases du métier changent.

Pour quelles approches et solutions ?

Cas n°1 – La mise en place d’une chaîne CI/CD avec Keyrus

Dans le cadre d’une reprise d’un ERP métier pour un client dans le secteur de la livraison d’ultra frais à domicile, nos équipes ont su collaborer avec notre partenaire Keyrus, spécialiste international du conseil en gestion et technologies de la performance. Ainsi, une chaîne d’intégration et développement continue (CI/CD) conforme aux méthodes de Keyrus a été déployée, afin de faciliter la mission TMA pour le compte du client final. Celle-ci privilégie la continuité de service, primordiale dans la gestion de produits ultra-frais. Le control plane de Kubernetes permet de s’assurer de la redondance des conteneurs dans les différents nœuds déployés. L’ajout du couple Prometheus / Grafana permet de suivre à l’aide de dashboard l’état de santé des conteneurs et des clusters.

Cas n°2 – Un modèle adapté au Web Agency

Une autre approche est celle d’une Web Agency, responsable du développement et la TMA d’une multitude de sites. La dimension industrielle recherchée est de pouvoir appliquer des opérations simultanément à un ensemble de sites et non de faire un traitement unitaire coûteux en temps et efforts. Avec notre client Gaya, nous avons pu imaginer une véritable « usine à sites » sur un socle unique. Cela permet au client d’avoir une totale liberté dans la gestion de ses mises à jour de contenu, tout en s’affranchissant des problématiques de versions et éditions de chaque environnement. Un travail continu permet d’optimiser la gestion de la performance des conteneurs. En effet, les fonctionnalités d’auto-scaling de Kubernetes couplées à un système de supervision Prometheus permettent d’ajuster la puissance des conteneurs et de s’assurer de la disponibilité des applications et des sites internet déployés.

Cas n°3 – L’adaptation de l’accompagnement à la maturité du client

La maturité du client va également déterminer l’approche de l’infogérant. Les clients précédemment nommés étaient déjà DevOps-ready a minima, voire matures sur la maîtrise de leur environnement spécifique.

Notre client Gedivote, spécialiste du vote électronique, a souhaité diversifier sa cible en adressant des PME et ETI, en complément de son marché historique de Grands Comptes français. De ce fait, le dispositif proposé ne pouvait pas être le même. Le service devait donc être adapté. Ainsi, Gedivote a souhaité étudier la conteneurisation pour cette solution, dans l’objectif de pouvoir déployer plus rapidement et en totale autonomie, le tout au rythme de sa réorganisation autour des méthodes Agiles. Le rôle d’un infogérant comme ITS Integra est donc plus axé sur un accompagnement fort pour guider le client, afin de guider le client sur les choix technologiques, en partant des objectifs métier concrets.

Nous pouvons alors avancer que la raison d’être des Services Managés reste finalement inchangée. Rester pertinent suppose tout de même d’acquérir de nouvelles méthodes et privilégier la compréhension du besoin à la technicité pure d’un ensemble de gestes à réaliser.

Les Services Managés ont encore de très beaux jours devant eux ! Ils restent avant tout essentiellement centrés sur les défis de transformation des clients.

Software-Defined Perimeter

L’architecture proposée par la Cloud Security Alliance en 2014 conserve les principes de l’architecture Zero Trust définie par le NIST avec la séparation du Control Plane et du Data Plane. Cette architecture utilise quatre composants logiques :

• SDP Controller : appareil ou processus sécurisant l’accès au service isolé en s’assurant que les utilisateurs sont authentifiés et autorisés à accéder au service avec un terminal validé. Il force aussi l’application de politiques supplémentaires pour que les communications établies soient sécurisées.
• Initiating Host (IH) : il représente le client où l’agent SDP est installé.
• Accepting Host (AH) : accepte les connexions sécurisées depuis les Ihs, il représente un ensemble de services protégés par le SDP.
• SDP Gateway : elle donne l’accès aux utilisateurs et terminaux autorisés aux processus et services protégés. Elle permet le monitoring, le logging et le reporting sur ces connexions.

Architecture Software-Defined Perimeter

Le fonctionnement de l’architecture SDP suit les étapes suivantes :

1. Le ou les SDP Controller(s) sont activés pour commencer à construire une architecture SDP. Le SDP Controller possède l’ensemble des informations concernant les accès autorisés aux différents éléments de l’architecture SDP.
2. Les Accepting SDP Hosts (AH) s’ajoutent auprès du SDP Controller. Souvent, les Accepting SDP Hosts (AH) sont derrière une SDP Gateway qui s’occupe d’établir la connexion et de communiquer avec le SDP Controller.
3. Les Initiating SDP Hosts (IH) s’ajoutent auprès du SDP Controller avec l’envoi du Single-Packet Authorization. Le SDP Controller a les clés utilisées par le Initiating SDP Hots pour authentifier le paquet.
4. Après connexion des différents composants auprès du SDP Controller, le SDP Controller contrôle la liste des Accepting SDP Hosts avec lesquels l’Initiating SDP Host a un accès autorisé.
5. Le SDP Controller prévient les Accepting SDP Hosts concernés que l’Initiating SDP Host en question est autorisé à communiquer avec eux.
6. Le SDP Controller envoie ensuite une liste des adresses IP des Accepting SDP Hosts autorisés à l’Initiating SDP Host.
7. L’Initiating SDP Host communique avec les Accepting SDP Hosts après établissement d’une communication bidirectionnelle chiffrée (utilisation du mutual TLS).

L’architecture SDP réutilise des principes déjà connus pour proposer une architecture Zero Trust.

Différences entre l’architecture BeyondCorp et l’architecture Software-Defined Perimeter

Une solution ZTNA

Une solution ZTNA suit les principes du modèle Zero Trust en ayant les fonctionnalités suivantes :

• Authentification multi-facteurs de l’utilisateur
• Vérification de conformité du terminal utilisé : PC, tablette, smartphone
• Interconnexions avec les fournisseurs d’identité et les solutions EDR
• Application de politiques d’accès selon le contexte
• Protection des services utilisant TCP et UDP
• Interconnexions avec les solutions SIEM pour l’envoi des logs

Deux approches sont adoptées par les éditeurs pour leurs solutions ZTNA. Ces approches identifiées par le Gartner, s’inspirent des modèles d’architecture Zero Trust de 2014 .

L’approche Service-Initiated ZTNA

Cette approche s’inspire du modèle BeyondCorp de Google. L’utilisateur s’authentifie depuis son navigateur web au portail hébergé sur le ZTNA Broker/Proxy. Après authentification et vérification, les ZTNA Connectors autorisés sont accessibles pour l’utilisateur.

L’avantage de ce modèle est de ne pas avoir besoin d’agent pour qu’un service soit accessible à un utilisateur. Le fait de ne pas avoir d’agent apporte aussi moins d’informations sur la conformité du terminal. Certaines ressources sont protégées par ce modèle comme les ressources Web, les accès en SSH et en RDP mais la prise en charge d’autres services est rare.

Service-Initiated ZTNA, Market Guide for Zero Trust Network Access, Gartner (2020)

Le type Endpoint-Initiated ZTNA

Ce modèle s’inspire du Software-Defined Perimeter où le ZTNA Controller correspond au SDP Controller. Dans un premier temps, l’utilisateur va s’authentifier auprès du ZTNA Controller qui va vérifier son identité et celle du terminal utilisé. Le ZTNA Controller renvoie ensuite la liste des applications auxquelles l’utilisateur est autorisé à accéder. Il prévient ensuite la ZTNA Gateway que cette paire utilisateur-terminal est autorisée à accéder à la ressource.

Les avantages du modèle sont similaires à ceux du Software-Defined Perimeter et présentent aussi les mêmes inconvénients. La nécessité d’avoir un agent bloque les terminaux non gérés par l’entreprise. Ce modèle propose néanmoins un niveau de vérification précis en s’appuyant sur des données récupérées par l’agent. Toutes les applications utilisant TCP ou UDP peuvent être protégées et sont accessibles.

Endpoint-Initiated ZTNA, Market Guide for Zero Trust Network Access, Gartner (2020)

Que ce soit une ZTNA Gateway ou un ZTNA Connector, le composant est déployé au plus près des ressources et n’accepte pas les flux entrants. Les ressources ne sont jamais exposées directement sur Internet.

Par Jérémy Lanoë – Consultant Infrastructure Security chez Almond