Optimiser la gestion de ses leasings informatiques
Optimiser la gestion de ses leasings informatiques
La location de matériel informatique représente un coût non négligeable pour les entreprises, mais ces dépenses ne sont pas toujours maîtrisées, malgré les processus de contrôle interne.
La location de matériel informatique représente un coût non négligeable pour les entreprises, mais ces dépenses ne sont pas toujours maîtrisées, malgré les processus de contrôle interne. En cause, un manque de communication et de rapprochement des suivis. Explications…
La location de matériel informatique coûte plusieurs milliards d’euros aux entreprises françaises chaque année. Suivie par les loueurs, la DSI, la comptabilité, les gestionnaires du parc et des stocks, … tout porte à croire que les coûts de location sont bien maîtrisés. En réalité, ces multiples suivis aboutissent à des résultats très différents, sans que personne dans l’entreprise n’ait vraiment conscience de la réalité.
La première étape du diagnostic, consiste tout d’abord à identifier les processus et les acteurs impliqués dans la gestion du matériel, et notamment du matériel loué.
Un écart potentiel entre les visions de l’Entreprise et la vision du Loueur
Visions de l’Entreprise
En pratique, la responsabilité de la gestion des matériels informatiques est souvent répartie sur plusieurs acteurs qui ont eux-mêmes des objectifs spécifiques.
De fait, la vision du contenu du parc diffère au sein même de la DSI. Les trois sources principales d’information sont : celle de la Gestion de Parc, celle des Equipes IT (réseau et/ou télédistribution), celle de la Finance…
Le service de Gestion de Parc assure un rôle de gestion des biens dans un outil spécialisé, définit des processus de mise à jour mais n’est généralement pas en charge de l’exécution des opérations. La fiabilité de la Gestion de Parc est donc tributaire de nombreux acteurs dont la rigueur conditionne la qualité de la Gestion de Parc.
Les Equipes IT ont une gestion très technique des équipements basée sur des outils et différentes bases qui permettent d’enregistrer les équipements. Les équipes Réseau et de télédistribution savent identifier les équipements connectés et les utilisateurs associés. Les mécanismes techniques d’inventaire et d’identification réseau permettent d’avoir des informations très précises sur les équipements connectés. Cependant, toutes les machines en « attente » : déconnectées, rangées dans des placards, cassées, prêtées ne peuvent être identifiées. De même, ces outils n’adressent pas les périphériques (souris, claviers, écrans, câbles), Bien entendu, les outils de collecte ne font aucune différence entre les machines louées et celles achetées.
Le contrôle de gestion de la DSI suit le coût des machines dans son budget. Il utilise parfois les outils du loueur et dispose de moyens limités pour contrôler la facturation du parc loué..
Au fil du temps, il y a donc distorsion entre les vues de la Gestion de Parc, des Equipes IT, du financier. Résultat : un écart d’au moins 20% entre les différentes visions constatées dans de nombreuses entreprises.
Vision du Loueur
De son côté, le loueur a une vision statique. Il suit tout ce qu’il a loué : les ordinateurs mais aussi les écrans et autres périphériques.
Sa gestion est totalement décorrélée du cycle de vie des équipements : il ne sait pas s’il y a des équipements cassés, des mobiles perdus ou des serveurs obsolètes inutilisés. D’une part, parce que l’ensemble du matériel loué, quel que soit son état, devra être payé jusqu’à la fin de la période de location initiale, d’autre part parce que le loueur n’a quasiment jamais les données nécessaires pour mettre à jour son suivi.
La fin de vie du matériel : trop tard pour constater les écarts de suivi
En fin de contrat, le loueur reçoit la liste du matériel à récupérer.
Ce matériel est préparé par l’Entreprise. Il est collecté tant bien que mal dans les différentes directions ou implantations qui souvent n’ont pas en charge la gestion de leur parc de machines.
Le matériel est récupéré par un transporteur, qui n’assure pas le contrôle. Il est stocké et il peut se passer plusieurs semaines avant que le loueur traite le matériel récupéré.
Ces multiples étapes nécessitent la mise en œuvre précise de processus souvent mal maîtrisés par les acteurs. Ainsi la gestion de parc n’est pas forcément informée des retours ou des matériels manquants.
Le loueur met à jour sa base, donc la vue financière, mais n’informe pas forcément l’équipe de gestion de parc des éventuels écarts.
Pour le loueur, les matériels non restitués continuent forcément à être loués.
Beaucoup d’entreprises continuent donc de payer ne sachant pas où est le matériel. Faute d’information, aucun contrat ne peut être clôturé, et peu d’entreprises utilisent à bon escient la clause de non-restitution.
Les multiples raisons des écarts
Une liste à la Prévert de « petites raisons » explique la dérive entre la réalité terrain et les informations des équipes qui assurent le suivi des matériels loués pendant la durée du contrat.
D’abord, l’informatique sait où sont les machines utilisées mais souvent peu d’analyses permettent de suivre les matériels obsolètes ; les ordinateurs remisés dans un placard, etc… L’urgence faisant loi, le smartphone cassé est remplacé au plus vite, et le vieux mobile est abandonné dans un tiroir.
Certaines machines sont récupérées par les collaborateurs. Il ne s’agit pas forcément de vol, mais d’équipement en double pour le travail à la maison. Même si le manager en est informé, il n’a généralement pas le réflexe de communiquer cette information au service de Gestion de Parc.
De plus, les DRH ou les managers ne savent pas que les postes sont loués et ils laissent parfois partir les collaborateurs avec leur portable ou leur tablette. Or, le matériel n’appartient pas à l’entreprise.
Pour toutes ces petites raisons, les équipements deviennent donc « invisibles » pour le Gestionnaire du Parc mais continuent à être bien réels pour le Loueur qui facture ses loyers.
Les mesures de suivi : d’abord plus de communication
La première chose est d’organiser la communication entre les services au sein de la DSI, mais aussi avec le management, la DRH… Tous doivent savoir que le matériel n’appartient pas à l’entreprise et qu’il ne peut être ni jeté, ni donné, ni vendu…. Le Loueur est le propriétaire
La mise en place d’outil de reporting (type tableau de bord), avec un rapprochement régulier entre les différentes sources d’information permet de déclencher des actions correctrices. A chaque mesure, l’entreprise réduira un peu plus les coûts du matériel informatique et de l’ensemble du parc informatique loué. La fonction de Gestionnaire de Parc est responsable de ce rapprochement. Il est, connu et reconnu, fera le lien entre la vision des utilisateurs, celles des différentes équipes (techniques, logistiques, comptables…) et les informations du loueur et suivra les plans d’actions.
Cependant il est difficile de sensibiliser tous les collaborateurs au fait que le matériel n’appartient pas à l’entreprise mais au loueur.
Il est donc important de prévoir dès la signature des contrats avec le Loueur, un taux de non-restitution pour réduire le coût d’éventuels matériels perdus à la fin de la période de location.
L’intérêt d’un contrat de location dépend entre autres de la capacité de l’Entreprise à gérer le cycle de vie de ses équipements (entrées, sorties, pertes, casses, ..) et du contenu de toutes les dispositions contractuelles associées (taux de non-restitution, type de matériel à restituer..).
Ecovadis confirme notre badge Gold cette année, avec la note de 69/100 qui nous positionne dans les 3% d’entreprises les mieux notées par Ecovadis.
Cette année encore, nous avons poursuivi nos actions sur l’ensemble des thématiques RSE (Environnement, Social, Sociétal, Ethique et Achats responsables), confirmant nos forces :
Mesure outillée de la satisfaction des collaborateurs
Mesure GDPR respectant les données des collaborateurs, clients, fournisseurs, …
Processus de recrutement transparent communiqué de manière claire et formelle aux candidats
Formation visant à développer les compétences
Mise en place de registres “matières” et “énergie”, afin d’identifier les actions pertinentes permettant de poursuivre la réduction de notre empreinte environnementale
Achat de nos ordinateurs, thé, café, cadeaux de fin d’année (miel issu de ruches parrainées par l’entreprise, coffrets gourmand bio, champagne bio, confitures Rebelle etc.), répondant à des critères environnementaux et sociaux
Étude approfondie de la performance sociale et des impacts sociétaux des organisations de travail “libérées” afin de développer davantage la performance globale de nos clients
Réduction drastique de notre utilisation du plastique (gobelets, couverts, …)
…
Confortés par ce résultat, nous nous attelons désormais à la définition du plan 2020 et nous sommes impatients de le partager avec vous.
Souvenez-vous ! Lors du dernier article, nous venions d’obtenir notre certification TOGAF et nous voulions voir comment appliquer ce framework dans la « vraie vie ». Nous avons donc mis en place Les capacités d’architecture (phase Préliminaire et phase A), et maintenant nous allons continuer en suivant la roue ADM (Architecture Development Method).
Nous allons donc parler dans cet article, de la définition des exigences propres à chaque niveau du Système d’Information (la couche métier, la couche applicative et la couche technique) et qui vont impacter le projet. Puis dans le prochain article, nous finirons avec leurs conséquences sur le design des solutions et comment fermer la roue.
La définition des exigences peut changer du tout au tout en fonction du domaine d’activité de votre entreprise / client. Culturellement, le domaine industriel a toujours été plus sensible à la rédaction des exigences que le domaine tertiaire. Vous imaginez bien que pour construire une centrale nucléaire, la liste des exigences est plus importante que pour construire une application de gestion de la solution client (CRM) car en cas de problème, les conséquences sont moins importantes.
Gestion des exigences ou le référentiel des exigences
La gestion des exigences doit permettre de s’assurer du bon suivi des exigences exprimées lors des différentes phases de la roue ADM mais également de s’assurer de leur cohérence. Pour cela, il faut 3 choses :
Un référentiel des exigences pour les stocker
Un processus de mise à jour
Un processus de revue pour la mise en cohérence des exigences.
TOGAF est un framework avec une approche « Test Driven Design ». C’est-à-dire que les exigences du système d’information ont pour but d’être testées. Il est donc primordial de bien les maîtriser de les prioriser, de connaître leur historique, de pouvoir les évaluer et de voir à la fin si le produit fini du projet y répond correctement.
Pour cela, il peut être intéressant d’outiller la gestion des exigences et de créer un référentiel. Si un outil existe déjà, utilisez-le, les plus connus sont IBM rational DOORS, Envision Requirements, JIRA ou autre. Dans le cas contraire un fichier Excel dont la gestion sera sous la responsabilité de l’architecte projet sera bien suffisant. De plus, les exigences seront gardées à la fin du projet et pourront être réutilisées lors du démarrage d’un nouveau cycle de la roue ADM. Il est alors préférable de nommer un responsable de l’administration de ce référentiel.
Maintenant que tout est prêt, nous pouvons continuer de parcourir la roue ADM et commencer à identifier les exigences auxquelles il va falloir répondre.
Phase B : Architecture métier ou comment solliciter son métier à bon escient ?
La phase B de la roue ADM doit permettre de décrire comment votre entreprise (ou le domaine métier impacté par votre projet) doit s’organiser pour atteindre les objectifs. Le travail va donc se concentrer sur la définition de la stratégie, sur la gouvernance, l’organisation métier et les informations clés des processus métier. Et comme lors des précédentes phases, le but est de ne pas surinvestir et de ne consommer que de la charge de travail avec une véritable valeur ajoutée.
La majorité du temps, les équipes d’architectes font partie de la DSI, les relations avec le métier peuvent donc être multiples :
Nous avons directement accès au métier et les impacts sur les processus sont faibles : La disponibilité du métier risque d’être faible car il a ses tâches récurrentes à effectuer (vente, gestion, comptabilité). Dans ce cas, il est nécessaire de lui prendre le moins de temps possible : traduire les enjeux métier, lister les processus et les « pain points ». Seuls quelques ateliers seront nécessaires pour collecter ces informations, il suffit ensuite d’en déduire les exigences métiers.
Nous avons directement accès au métier et les impacts sur le métier sont importants : dans ce cas, le métier doit se rendre disponible pour répondre au besoin. C’est généralement le cas préféré des architectes car cela permet de poser ses questions en toute liberté.
Nous devons passer par une MOA, qui est un intermédiaire avec le métier. L’avantage de cette relation est qu’une MOA est intégrée dans le projet et qu’elle se rendra disponible pour répondre aux besoins du projet. Le problème est que la MOA n’est pas forcément au courant des enjeux du métier, selon l’organisation mise en place entre la DSI et le métier.
Une fois que les exigences métiers sont identifiées et le référentiel mis à jour, nous pouvons passer aux exigences liées au système d’information.
Phase C : L’architecture du système informatique car même l’IT a ses propres exigences…
Les exigences du système d’informations se découpent en 2 catégories. Celles qui s’appliquent à l’intégralité du système d’information et celles qui s’appliquent au projet.
Les exigences qui s’appliquent à tout le SI sont souvent les plus faciles à appréhender pour les architectes : ce sont les exigences d’architecture que nous connaissons tous comme :
Un identifiant doit être unique et non interprétable.
Une fonction ne peut pas être implémentée plusieurs fois dans le SI…
La séparation des fonctions de production et de distribution,
Celles liées aux échanges (API, couche d’échange…),
Sur les sources de données (le terme de « Golden Source » est souvent utilisé),
Ou les réglementations comme sur la protection des données (Règlement Général sur la Protection des Données, ….).
Puis viennent toutes les exigences spécifiques au projet en lui-même comme celles liées à la confidentialité, l’intégrité, la disponibilité ou l’authentification / identification. La mise à niveau des exigences précédemment édictées par le métier est souvent négligée. Quand cette mise à niveau n’est pas faite (peu importe le formalisme), cela révèle souvent un manque de dialogue entre les équipes projet métier et IT. Cet effort est nécessaire car une partie de la valeur de l’architecte est justement de créer un pont entre ces deux mondes.
Phase D : Architecture technique
Dans les DSI importantes, des architectes dédiés ont généralement la charge de la partie technique. En effet, un architecte ne peut pas avoir le même niveau d’expertise sur toutes les couches du système d’information et la frontière se trouve historiquement à ce niveau. Dans les DSI plus petites, la césure entre les architectes techniques et les architectes fonctionnels est moins importante mais elle existe souvent malgré tout.
L’architecte technique doit avoir une bonne connaissance du catalogue des normes et standards de l’entreprise. Savoir quels sont les composants (technologies, logiciels…) à utiliser, où en est leur cycle de vie et les mettre en regard du projet. L’architecte se confronte également à la stratégie de la DSI et à sa politique fournisseurs notamment (quand elle existe).
Dans le cas de solutions hébergées en interne, l’architecte technique doit définir les exigences techniques qui permettent de dimensionner correctement l’infrastructure. Dans le cas de solutions Cloud ou d’application en SAAS, les exigences liées aux infrastructures n’ont plus de raison d’être, elles doivent être définies en termes de SLA (plus besoin de calculer le nombre de serveurs, car l’hébergeur est garant du dimensionnement). Dans ce dernier cas, s’occuper des interfaces est plus que nécessaire.
A la fin de cette phase, le référentiel d’architecture doit s’enrichir en précisant les composants à utiliser pour atteindre la cible désirée et la feuille de route provisoire avec les recommandations de mises en œuvre.
Conclusion
A ce niveau d’avancement, nous avons pu collecter et finaliser l’ensemble des exigences du projet. Nous avons également une vue assez claire d’où nous partons et où nous voulons aller, sauf que nous sommes encore dans un monde « sans contrainte ». Nous savons ce que nous voulons (ou ne voulons pas) mais il faut à présent se confronter au monde réel, fait de contraintes de planning, de budget, de disponibilités des ressources et donc sortir de cette tour d’ivoire où se sont parfois enfermés d’autres architectes avant vous. Les négociations et les arbitrages commencent et la valeur tangible apportées aux projets se mesure ici, comme nous le verrons dans le troisième et dernier article de cette série sur TOGAF In Real Life.
L’erreur la plus commune, quand on entreprend une démarche micro services, est de vouloir découper en micro-services !
Le concept de micro services existe désormais depuis une dizaine d’années. Netflix étant la première « grande entreprise » (si on pouvait la nommer ainsi à l’époque) à adopter une telle orientation.
Avec le recul, le plus gros problème des micro services repose sur le fait de les avoir appelés « micro ». En lisant sur Wikipedia, on retrouve sous le chapitre « Philosophie », la phrase suivante : « Les services sont petits, et conçus pour remplir une seule fonction ».
Rien de plus incorrect si on veut bien entamer une démarche micro services… Tout comme parler de nano services et macro services, pour analyser des mauvaises pratiques, comme font certains acteurs. Ce n’est pas une question de taille !
Les efforts doivent principalement se focaliser sur trois axes fondamentaux dans la réflexion sur le découpage :
SIMPLICITÉ : un micro-service doit être spécialisé. Il ne doit pas avoir une couverture fonctionnelle complexe, il doit effectuer un ensemble d’actions simples et ciblées. Ceci étant dit, nous ne devons pas non plus réduire un microservice à une simple fonction, dans l’objectif de “faire petit” : un microservice doit couvrir un ensemble fonctionnel cohérent.
ISOLATION : un microservice doit être isolé des autres. Le dysfonctionnement d’un microservice ne doit pas impacter les autres afin d’éviter l’effet domino.
INDÉPENDANCE : un microservice garantit son indépendance, il englobe tout ce qui lui est nécessaire pour son fonctionnement. Dans la décennie de la containérisation, tout a été mis en œuvre pour que le concept d’indépendance, associé aux microservices, devienne simple et intuitif. Un container de par sa nature est facilement associable à un microservice
A partir de ces considérations, quelle est la meilleure approche pour définir le périmètre de ses micro services ?
Partons du besoin primaire d’un SI : Traiter de la donnée ! Conjuguons ce besoin à une autre caractéristique des micro services : un micro service interagit avec une donnée qui lui est propre. Une solution simple se propose : réalisons un découpage par la donnée ! Le premier pas pour dessiner un découpage des microservices est de définir la structure de la donnée.
Prenons un exemple très simple : le triptyque CLIENT, PRODUIT et ORDRE.
Dans la logique que je viens d’expliquer, nous pouvons construire un Microservice sur chaque entité métier :
Ce qui permet à une application frontale de combiner les trois pour, par exemple, permettre à un site d’eCommerce, de :
passer un ordre
après avoir consulté la liste des produits
et avoir géré l’inscription d’un client
Cette démarche n’est certainement pas exhaustive. Chaque cas de figure nécessite une analyse à part entière, mais à notre sens c’est un bon point de départ pour une réflexion micro service.
Pour résumer, une bonne pratique de découpage en micro services est initiée par le découpage de la donnée, en entités métier.
Voici une vidéo créée par nos soins pour illustrer ces explications : ici
Conclusion
Essayer de faire « petit » n’est pas forcément le sujet sur lequel focaliser ses efforts… L’indépendance et l’isolation sont les clés d’une bonne démarche micro-services. Si un doute surgit, le mieux est de ne pas découper tant que les autres principes sont respectés.
Les autres articles qui peuvent vous intéresser
IoT – Une gouvernance à double niveau semée d’embûches
IoT - Une gouvernance à double niveau semée d'embûches
Qui n’a jamais tremblé lorsque le post-it “Définir le Target Operating Model (TOM)”, alias Gouvernance, lui a été attribué ?
Il s’agit là d’une activité complexe mais pourtant au combien nécessaire pour l’efficacité et la pérennité d’une offre ou d’un service.
La Gouvernance IoT n’échappe pas à ce constat général, la difficulté en est même démultipliée :
l’IoT s’applique à une diversité de Métiers ayant chacun leurs particularités,
la chaîne IoT nécessaire à un cas d’usage métier est constituée de nombreux maillons technologiques (cf. notre article IoT Un Marché en pleine ébullition) répartis sur un large spectre de compétences.
Quelle part de responsabilité attribuer aux Métiers / à l’IT ? Comment définir une structure commune transverse à l’échelle de l’Entreprise ? Comment fédérer les initiatives locales pour les encadrer et démultiplier les bénéfices ? Quel RACI peut être mis en place ?
IoT, flagrant délit de franchissement de ligne, de l’Information Technology (IT) vers les Operational Technology (Métier)
Comme nous l’avons évoqué dans notre précédent article, les technologies IoT s’immiscent sur des cas d’usages purement métier assurés jusque là par des Operational Technology.
Les Métiers étaient et sont toujours les sachants sur :
Le contexte et les finalités du cas d’application,
Les contraintes environnementales applicables (vibration, climatique, form factor, interférence, …),
Les données pertinentes à récolter, et leurs fréquences,
Les traitements métiers à appliquer sur les données pour obtenir les informations nécessaires au cas d’usage ciblé.
L’IT apporte son expertise sur les différentes couches technologiques :
Les infrastructures à mettre en oeuvre,
Les objets connectés (ou composant) à utiliser,
Les plateformes qu’elles soient on-premise ou en mode PaaS / SaaS,
La connectivité (les protocoles réseaux adéquats…),
Les best practices et pattern d’intégration pour véhiculer, stocker et partager l’information,
La sécurité sur l’ensemble de la chaîne.
De facto, nous identifions rapidement les risques à adopter une Gouvernance portée de façon unilatérale par :
Le Métier : solution non pérenne technologiquement ou ne répondant pas aux standards de l’entreprise, solution propriétaire “vendor lock-in”, solution sous-dimensionnée, …
L’IT : une couverture fonctionnelle non adaptée aux besoins réels (trou dans la raquette VS Rolls-Royce), une solution trop rigide et peu évolutive au regard des transformations du métier, …
Il y a donc une vraie dualité Métier / IT à mettre en oeuvre au niveau de la Gouvernance.
Une Gouvernance mixte, N approches
Personne aujourd’hui ne saura en mesure de vous conseiller de procéder comme-ceci ou comme celà sans avoir sondé votre existant :
Quelle est le degré d’autonomie des entités opérationnelles ?
Les métiers disposent-ils de ressources IT propres ?
Est-ce que les directives IT sont centralisées ?
Les cas d’usages IoT sont-ils déjà bien ancrés en transverse dans l’entreprise ou bien largement isolés ? Est-ce qu’une équipe dispose d’une vision globale sur toutes les initiatives / tous les projets ?
Est-ce qu’il y a déjà des affinités à positionner telle entité sur le BUILD ou le RUN de tel ou tels maillons d’une chaîne IoT ?
Est-ce que quelqu’un dispose de la vision bout en bout entre le cas d’usage et les moyens IT à mettre en oeuvre pour le traiter ?
Comment renseigneriez-vous les quelques éléments ci-dessous ?
Néanmoins quelques modèles de gouvernance IoT émergent. Ci-dessous une illustration non-exhaustive :
Filière 1 : Miser sur un socle IoT transverse à l’entreprise
Le Groupe est un enabler pour les métiers :
Le Digital est en charge de la définition de la stratégie IoT Groupe,
Le département IT, est responsable de la mise en oeuvre des socles / plateformes IoT (horizontales), d’accompagner et de supporter les métiers dans leurs projets.
Les Métiers sont responsables de leurs projets IoT positionnés en verticaux.
Filière 2 : Miser sur l’agilité d’une Feature Team pour délivrer des solutions sur mesure
Les Métiers sont à l’origine des projets IoT,
Le département IT dédie des ressources à l’IoT dans ses différentes équipes (infrastructure, plateforme, réseaux, développement…). Ces ressources s’organisent généralement en Features Teams pour accompagner les projets métiers IoT avec le maximum de réactivité.
Et vous, vers quel modèle vous projetez-vous ?
Les victoires collectives sont les plus belles
La définition d’une Gouvernance est toujours complexe.
L’instruction d’un sujet IoT de bout en bout n’est pas une mince affaire. Cela requiert énormément de compétences technologiques (électronique, hardware, software, en passant par les télécoms…), tout en devant constamment s’assurer de l’adéquation avec la réalité terrain (contraintes mécaniques, etc.).
De là à dire que définir une Gouvernance IoT est impossible, il n’y a qu’un pas.
Métier et IT doivent travailler main dans la main, le fossé les séparant devant être définitivement comblé.
Adopter une démarche d’Open Innovation (ateliers d’idéation, fablabs, pizza teams…) permettra de casser les silos, de cadrer et d’affiner le “Qui fait Quoi ?” dans cet écosystème en constante évolution.
#Teasing : dans un prochain article nous vous parlerons des différentes stratégies, des positionnements possibles pour mettre sur le marché une Offre IoT.
L’adoption du Cloud Public par les entreprises est une réalité et plusieurs d’entre elles ont fait le choix d’adopter cette stratégie dans le cadre de leur transformation digitale. Avoir une stratégie Cloud First pour une entreprise consiste à utiliser des services ou infrastructures Cloud par défaut pour répondre à toute nouvelle application, processus ou fonction. Mais l’adoption d’une stratégie Cloud First est-elle une bonne idée? Répond-elle aux promesses de réduction des coûts ou de gain en agilité? Faut-il foncer tête baissée avec une approche jusqu’au-boutiste? Cloud First, mythe ou réalité ?
Nous allons essayer de répondre à ses différentes questions en vous présentant les 5 mythes les plus répandus lors du cadrage d’une stratégie Cloud First !
Mythe #1 : Le cloud vous permettra de réduire vos coûts liés à l’infrastructure
Faux ! Ne pensez surtout pas que par défaut vous réaliserez des économies en migrant votre application sur le Cloud. Établissez très vite une grille de critères et un arbre de décision pour opter pour la meilleure stratégie de migration pour chaque socle applicatif et n’hésitez pas à décommissionner lorsque vous le pouvez.
Exemple d’arbre de décision “Go to Cloud”
Mythe #2 : Toute application est éligible au cloud public
Faux ! Il ne convient pas également de supposer que toutes vos applications ou processus métiers devraient s’exécuter sur le Cloud Public. Ce sera adapté dans certains cas et pour d’autres il faudra convenir du bon scénario (Cloud Privé, Serveurs physiques) en prenant le temps d’évaluer les bénéfices et les risques.
Mythe #3 : Il vous faut choisir un fournisseur cloud privilégié qui deviendra l’option par défaut
Faux ! Une stratégie Cloud First ne signifie pas pour autant se lier à un seul ou deux fournisseurs avec un catalogue de services le plus important possible. Il ne faut pas oublier qu’il n’y a pas que AWS, Azure et GCP sur le marché. D’ailleurs en terme de sourcing, il sera préférable d’éviter d’être complètement dépendant d’un fournisseur unique. Il existe pléthore de fournisseurs cloud, notamment SaaS, qui sont souvent plus adaptés pour certaines catégories d’applications pour des fonctions support ou de back-office (messagerie, outils de collaboration, crm, erp, etc.). Dans ce cas précis, une stratégie “Best-of-breed” où vous retenez la solution répondant au mieux dans l’état de l’art en service SaaS puis dans un deuxième temps la meilleure architecture solution via le catalogue de service de votre fournisseur Cloud Public privilégié peut être une meilleur stratégie. Si vous choisissez cette option, nous vous conseillons de déployer une Hybrid Integration Platform (HIP) pour gérer vos échanges de données.
Mythe #4 : Migrer votre application vers le cloud la rendra automatiquement plus résiliente
Faux ! Le SLA ou engagement de service pour un service Cloud sur Azure par exemple est de 99,95%. Bien que ce chiffre puisse paraître important et suffisant, cela signifie tout de même qu’il sera toléré par le fournisseur que le service soit arrêté ou en panne pendant 4 heures par mois, soit 2 jours par an en cumulés ! Or, plusieurs fonctions ou applications métier ou techniques nécessitent des engagements de service plus élevés. Afin de bénéficier d’une meilleure résilience de vos services sur le Cloud public, il sera nécessaire de revoir la conception de votre application et de choisir des principes d’architecture haute disponibilité distribuée adaptés à cet environnement pour rendre vos applications « Cloud Native » : «event-driven », fonctions isolées et indépendantes, « data centric », « stateless », etc.
Mythe #5 : une fois dans le cloud, la fonction d’architecture technique ne sera plus nécessaire
Faux ! Il vous sera toujours nécessaire d’avoir des architectes techniques pour supporter les besoins suivants :
Gouverner, surveiller et sécuriser le Cloud,
Estimer les coûts d’infrastructure pour vos prévisions budgétaires,
Faire des recommandations d’optimisation d’architecture solution et technique,
Automatiser des processus liés à la gestion et au déploiement de solution/infrastructure,
Maintenir et mettre à jour votre catalogue de services et les patterns d’architectures Cloud associés,
Réaliser de la veille techno et évaluer de nouveaux produits et fonctionnalités offerts par vos fournisseurs,
Implémenter des outils annexes pour compléter ceux disponibles dans le Cloud en tenant compte des résultats de votre veille techno.
Il sera donc primordial de nommer un Lead Cloud Architect et d’avoir votre centre d’expertise d’architecture technique Cloud pour assurer ces tâches. Evitez le piège d’énoncer uniquement des principes théoriques à suivre par les projets et prenez le temps d’expérimenter les modèles ou tester vos hypothèses.
