Accueil > Digital Factory : quel socle technique mettre en place ?
Laurent Yin
9 mars 2022
Read this post in English

Digital Factory : quel socle technique mettre en place ?

Digital Factory : quel socle technique mettre en place ?

Article corédigé par Laurent Yin et Aly-Bocar Cissé (Cellenza) & Eric Grenon et Elliott Pierret (Microsoft)

Afin de mettre en place des Digital Factories répondant aux ambitions stratégiques portées par cette entité, il est fondamental de disposer d’un socle technique solide et évolutif.

 

Livre blanc digital factory Cellenza

Les architectures Cloud au service du time-to-market

 

Le principal aspect à aborder est le time-to-market. En effet, si une Digital Factory ne peut répondre aux attentes des utilisateurs en créant des produits numériques à un rythme soutenu, l’initiative se soldera par de la déception. Il est indispensable de prendre le temps et d’être méthodologique pour s’assurer que la technique est alignée aux enjeux métiers identifiés. De ce fait, dans l’environnement IT actuel, les architectures centrées sur le Cloud s’imposent naturellement. L’allocation instantanée de ressources, les fonctionnalités de déploiement automatisé et la scalabilité des ressources sont primordiales pour les Digital Factories. De plus, plutôt que d’être une brèche pour la sécurité du système d’information, comme cela a pu être évoqué au début de l’émergence du Cloud, la tendance actuelle est plutôt d’exploiter la convergence des plateformes afin d’imposer des règles de sécurité persistantes sur du moyen et long terme.

Pour démarrer sur le socle technique, organiser correctement les ressources Cloud est un bon point de départ. On parle alors de Landing Zone Cloud. Cela permet d’avoir le plan qui représente la fondation sur laquelle vont reposer les ressources déployées au sein du Cloud, ce qui concerne particulièrement les Digital Factories. Comme tout plan d’urbanisation avec une projection sur l’avenir, le réseau, la sécurité, la consistance et la gouvernance sont primordiaux pour définir cette Landing Zone. C’est sur cette base que s’appuieront ensuite les déploiements de containers ou d’architectures serverless.

 

Une base réseau évolutive pour le socle technique

 

Le modèle qui s’impose sur l’organisation technique du Cloud est le Hub-and-Spoke. Ce type d’architecte se démarque sur trois aspects :

  • Connectivité
  • Sécurité
  • Évolutivité

Digital Factory Hub and spoke

 

En implémentant cette topologie, l’accent est d’emblée porté sur les interactions entre la Digital Factory et le système d’information. Cela permet d’éviter l’existence de plateforme « Shadow », isolée du système d’information et sans aucune forme de gouvernance. Le « Hub » joue le rôle de composant central, cette couche assurant entre autres le rôle de connectivité entre le Cloud et les ressources déployées à demeure.  Les applications déployées sur la Digital Factory ne seront, quant à elles, pas branchées directement au réseau on-premise mais devront nécessairement se brancher sur le Hub. On parle alors de « Spokes ». De cette façon, on mutualise la connectivité, ce qui apporte des gains en termes de coût et de temps. La gestion est également plus explicite et les différents spokes sont isolés de sorte que l’un n’affecte pas l’autre.

Cette topologie renforce la sécurité car il est possible d’imposer la sécurité sur le Hub, passage obligé dans cette organisation en « étoile ». On pourra alors y positionner un firewall ou d’autres composants mutualisables comme des DNS ou des bastions qui jouent le rôle de relais lorsque l’on souhaite se connecter sur une ressource déployée dans le Hub-and-Spoke. Les systèmes de supervision ou de sécurité comme le SIEM pourront intervenir à ce niveau, ce qui permet d’apporter une maîtrise à une échelle globale et centrale.

Les avantages en termes d’évolutivité sont présents, dans la mesure où il est possible de rajouter simplement un Spoke sans affecter les autres. Les ressources déployées dans ce Spoke appartiennent alors à un périmètre défini, qui n’influe pas sur les ressources des autres projets par exemple. On est alors garanti de l’extensibilité de la Digital Factory, reflétant les ambitions sur l’on se donne sur ce type de plateforme.

Sur le Cloud proposé par Microsoft, cette architecture se matérialise notamment en utilisant des Virtual Network, reliés entre eux par du VNET Peering. Lors de la conception, il faut bien anticiper les plages IP qui seront utilisées par la suite, en se projetant sur du moyen terme a minima. Cette configuration peut être réalisée même si les Virtual Networks sont déclarés dans des souscriptions différentes, ce qui permet de profiter d’une autonomie entre le Hub et entre les Spokes. L’utilisation d’Azure Virtual WAN facilite cette configuration à grande échelle, en regroupant les configurations réseau, de sécurité et de routage au niveau d’une interface unique.

Pour réaliser la connectivité entre le Cloud et les instances à demeure, Azure ExpressRoute est à privilégier pour pouvoir profiter d’un lien réseau privé. Le Virtual Network du Hub est alors connecté au réseau à demeure. Notons que le VPN peut également être utilisé, même si un lien privé est préférable. Ensuite, chaque Spoke relié au Hub peut bénéficier de la connectivité vers les ressources internes. Pour cela, l’utilisation des User Defined Routes sur Azure permet de router le trafic réseau sur les bonnes cibles.

La configuration des Network Security Groups permet la maîtrise des flux entrants et sortants des différents réseaux. La sécurité sur les VNET peut être renforcée par un composant installé au niveau du Hub : Azure Firewall. On centralise ainsi les opérations réseaux contribuant à la sécurité de l’architecture Hub-and-Spoke. Azure Monitor peut être configuré au niveau du Hub, en tant que composant partagé qui permettra de collecter les différents logs de la plateforme. Cela permet le paramétrage d’alertes de façon industrialisée.

 

Intégrer la dimension applicative

 

Au-delà des composants réseaux qu’il est pertinent d’organiser pour tenir compte de l’évolutivité des Digital Factories, il est pertinent de se projeter dans l’implémentation de solutions digitales à l’échelle. Cela se traduit par un approche orientée APIs, ce qui permet aux différents types de clients (PC, mobiles, objets connectés, applications…) de récupérer des données et de déclencher des opérations à travers un squelette unifié.

 

API Management Digital Factory

Pour pouvoir gérer ces APIs de façon efficace, les systèmes d’information s’appuient sur un composant-clé : l’API Management. Les APIs peuvent ainsi être exposées de façon sécurisée et être gouvernées sans développement préalable, grâce à l’API Management qui est un middleware fournissant ces fonctionnalités. Cela permet par ailleurs d’optimiser la gestion des applications consommatrices à travers une vision produit, et de suivre l’usage des APIs pour mieux les promouvoir. Dans certains contextes, la monétisation des APIs est exploitée dans l’API Management.

Ce composant étant global, il est généralement positionné en tant que service partagé au sein du système d’information et a sa place dans la Digital Factory de par la pertinence de son offre. Par exemple, sur Azure, il est possible d’exploiter le service Azure API Management et de lui assigner un Spoke dédié, mais sur lequel pourront s’appuyer toutes les ressources déployées dans l’architecture Hub-and-Spoke. L’API Management peut être instancié dans un réseau virtuel et profiter de la même connectivité vers les ressources à demeure.

 

Exemple d’API Management chez un acteur du e-commerceExemple d’API Management chez un acteur du e-commerce

 

Pour compléter l’architecture applicative type, les Spokes sont souvent instanciés avec des ressources PaaS, pour privilégier le time-to-market et la génération de valeur. On peut ainsi dépenser moins de temps et d’efforts sur la maintenance de l’infrastructure technique. Les fournisseurs Cloud valorisent également le modèle PaaS. Les architectures types sur Azure mettent en avant l’App Service pour le déploiement d’application web et de ressources de calcul. Le stockage de données peut être couvert par Azure SQL pour les données SQL, Azure Cosmos Db pour les données NoSQL, et Azure Storage pour les données non structurées. La sécurisation des applications peut être complétée par l’Azure Application Gateway, paramétrable en tant que Web Application Firewall. Azure Key Vault est un outil à exploiter pour la gestion des secrets. Enfin, pour garantir une bonne opérabilité avec de la supervision, AppInsights et Log Analytics sont à privilégier.

 

Architecture Azure Digital Factory

Les Digital Factories ont également une vocation d’innovation, avec pour finalité une industrialisation des services avec déploiement en production. Les dernières perspectives technologiques ont fait émerger des thématiques autour des flux et du traitement de la donnée, du serverless ou encore sur les containers. Le Cloud doit être exploité pour promouvoir ces opportunités, par l’implémentation de containers (CaaS pour Container-as-a-Service), de fonctions (FaaS pour Functions-as-a-Service), ou de flux d’intégration orientés Cloud (iPaaS pour integration-Platform-as-a-Service). C’est en s’appuyant sur ces nouvelles possibilités et en les déployant à grande échelle qu’on peut construire des Digital Factories impactantes, qui gardent une maîtrise de la gestion de la maintenance. Pour ce faire, sur Azure par exemple, on retrouvera des services gérés nativement par le Cloud comme Azure Kubernetes Service, Azure Container Registry, Azure Functions, Azure Service Bus, Azure Data Factory et Azure DataBricks qui outillent ces démarches et renforcent le socle technique. L’industrialisation de plateformes autour de l’IoT est également pertinente à approfondir.

C’est ainsi que le Cloud se doit d’offrir la flexibilité nécessaire et des services pour activer au mieux les initiatives numériques en entreprise, répondant à un éventail de besoins toujours plus large. L’élaboration de tableaux de bord de suivi des services et des usages permet d’assurer la convergence de ces initiatives. Cela alimente de surcroît un dynamisme qui doit être au cœur des Digital Factories.

 

 

Livre blanc digital factory Cellenza

 

Outillage de sécurité intégré

 

La Digital Factory représente un élément stratégique dans l’entreprise, c’est pourquoi il est nécessaire de porter une attention particulière aux notions de sécurité et de conformité. Compte tenu de l’ouverture du système d’information et de la diversité technologique qui le constitue, la surface d’attaque est de plus en plus importante. L’adoption de méthodes d’évaluation continue est primordiale pour assurer la pérennité des projets déployés sur la Digital Factory. Les tests de pénétration réalisés par des organismes d’audit reconnus sont toujours nécessaires, mais ils se font à un instant donné, pour une configuration précise. La sécurité et la conformité du système d’information doit désormais être éprouvée à un rythme plus soutenu avec des recommandations de sécurité et des alertes en quasi-temps réel.

Pour traiter ces considérations, il faut se doter d’une solution globale pour détecter les alertes, apporter davantage de visibilité sur l’état actuel du système et être capable de réagir de façon proactive aux failles remontées. Cette solution doit couvrir toute la Digital Factory, de sorte que l’ajout d’une nouvelle ressource ne se fasse pas au détriment de la sécurité du SI. C’est particulièrement le cas lorsqu’une nouvelle technologie est intégrée dans la Digital Factory ; il est donc indispensable d’étudier chaque type de ressource avant de l’exploiter en tant que composant de référence. La scalabilité étant inhérente au Cloud, elle doit également faire partie des caractéristiques de la sécurité d’une Digital Factory. La collecte des données permettant d’éviter les failles de sécurité se fait alors également à grande échelle.

Il ne s’agit évidemment pas de laisser les alertes détectées non gérées. Chaque événement sensible qui est déclenché doit être accompagné de suggestions pour résoudre le problème. L’automatisation pour appliquer les recommandations de sécurité est une piste qu’il est nécessaire d’exploiter : on rejoint des pratiques liées au DevSecOps, où la sécurité doit également évoluer pour aller de pair avec les processus de développement, de déploiement et de maintenance agiles. La réactivité est d’autant plus nécessaire, car il faut être capable de répondre rapidement, par exemple lorsqu’une faille est révélée par l’actualité IT. Plutôt que de perturber les jalons projet initialement positionnés lorsqu’une vulnérabilité critique apparaît, il devient naturel d’absorber ces actions de remédiation si elles font partie intégrante des fondations de sécurité qui portent la Digital Factory.

Ainsi, vous devez intégrer dès la construction de votre Digital Factory tous les éléments de sécurité, monitoring, agents de supervision, collecte des logs, analyse des menaces. L’avantage du Cloud, c’est que vous pouvez facilement déployer ces services et que vous bénéficiez directement d’une parfaite intégration.

Par exemple, si vous déployez des machines virtuelles, vous voulez avoir immédiatement la capacité de vérifier que celles-ci sont en accord avec les bonnes pratiques. Vous souhaitez aussi collecter les journaux d’évènements, appliquer un antivirus, configurer un firewall, etc. De même si vous utilisez des conteneurs, vous voulez que les images soient analysées avec un moteur de scan de vulnérabilités par exemple.

Il vous faut aussi un système de collecte et centralisation des événements pour analyser les signaux venant de tous les services de votre Digital Factory. Idéalement, une fois la corrélation de signaux effectuée, vous souhaitez appliquer des actions correctives.

Pour répondre à ces exigences, vous pouvez par exemple utiliser deux services sur Azure : Microsoft Defender for Cloud et Microsoft Sentinel. Examinons plus en détails ces deux services dont l’utilisation permet de sécuriser tous les aspects de votre Digital Factory.

 

Microsoft Defender for Cloud

 

Microsoft Defender for Cloud fournit les outils nécessaires pour renforcer vos ressources, suivre votre posture de sécurité, vous protéger contre les cyberattaques et rationaliser la gestion de la sécurité. Parce qu’il est intégré nativement dans Microsoft Azure, le déploiement de Defender for Cloud est facile, vous offrant un provisionnement automatique simple pour sécuriser par défaut vos ressources.

Ce service couvre trois besoins de sécurité :

  • L’évaluation continue, pour comprendre la posture de sécurité actuelle, en vous indiquant à tout moment votre score de sécurité basé sur une analyse de vos environnements Azure.
  • Les recommandations de sécurité: l’outil propose une liste de tâches de renforcement personnalisées et hiérarchisées pour améliorer votre posture de sécurité. Vous implémentez une recommandation en suivant les étapes de correction détaillées fournies dans la recommandation. Pour de nombreuses recommandations, Defender for Cloud propose un bouton « Fix » pour une mise en œuvre automatisée !
  • Les alertes de sécurité : grâce aux fonctionnalités de sécurité améliorées activées, Defender for Cloud détecte les menaces qui pèsent sur vos ressources et vos charges de travail. Ces alertes apparaissent dans le portail Azure et Defender for Cloud peut également les envoyer par courrier électronique. Les alertes peuvent également être diffusées vers des solutions SIEM et SOAR.

 

 

Microsoft Defender for Cloud Digital Factory

 

Microsoft Sentinel, la solution de SIEM et SOAR

Microsoft Sentinel assure une analyse de sécurité intelligente et fournit des renseignements sur les menaces dans l’ensemble de l’entreprise. Elle constitue une solution unique pour la détection des alertes, la visibilité des menaces, la chasse proactive et la réponse aux menaces. L’intelligence artificielle est mise à profit pour identifier les activités douteuses tout en réduisant la probabilité de réagir suite à la détection de faux positifs. On sait notamment à quel point les alertes qui ne sont pas pertinentes peuvent polluer la supervision de la Digital Factory. Il est alors indispensable de tout faire pour les éviter, dès la conception du socle technique.

 

Microsoft Azure Sentinel

 

Catalogue de Services de la Digital Factory

 

Votre Digital Factory se doit d’offrir des services. Ces derniers sont à destination des usagers de la Digital Factory. Quelle que soit la façon dont vous choisissez de construire ces services, les rendre disponibles à vos usagers reste l’essentiel. En clair, votre service est disponible si vos usagers :

  • Ont la capacité de découvrir vos services à défaut d’être notifiés de leur existence ;
  • Ont accès à vos services ;
  • Ont accès à une documentation de qualité ;
  • Ont accès aux conditions d’utilisations de vos services.

 

Les quatre points définis ci-dessus sont essentiels si l’on souhaite pouvoir commencer à parler de la notion de « Catalogue de services ». Les principaux « usagers » dont nous parlons ici sont les développeurs qui travaillent au sein de votre Digital Factory. Il est cependant possible que la nature de certains services concerne des populations autres que les développeurs. Nous resterons donc ici sur le terme d’usagers.

Comme toute initiative significative au sein d’une Digital Factory, le catalogue de services doit pouvoir gérer de façon automatisée l’intégration de services mais également permettre aux usagers de déployer ces derniers au sein de leurs projets.

Dans les faits, arriver à ce niveau de maturité requiert beaucoup de temps, notamment à cause principalement des points techniques suivants :

  • Une politique d’authentification uniforme au sein de votre Digital Factory. Avoir la capacité d’identifier tous les types d’utilisateurs et de ressources est une condition essentielle d’un point de vue sécurité mais aussi gouvernance. Ne pas être en mesure d’identifier qui souscrit à votre service est un frein à toute stratégie d’automatisation.
  • Une politique d’autorisation uniforme au sein de votre Digital Factory. L’aspect sécurité est également évident sur ce point. La gestion des autorisations de vos utilisateurs coule de source ; celle qui parait moins évidente est la gestion des autorisations pour vos services. En effet, vos services seront sûrement dépendants d’autres services pour arriver à vos fins.
  • L’intégration de vos services aux Architectures Cloud de vos usagers. Comme vu précédemment, ces architectures sont une nécessité pour les impératifs de sécurité et de time-to-market ». On peut généralement constater deux grandes catégories de services : les services qui étendent les capacités de vos architectures ou les services qui spécialisent ces architectures. Dans les deux cas, concevoir des services compatibles avec ces architectures est donc absolument nécessaire si vous souhaitez qu’ils soient utilisés en conformité avec les attentes de vos usagers.
  • Le déploiement de vos services au sein des projets. Il est d’usage de séparer le fait de concevoir des services qui s’inscrivent dans les architectures de vos usagers et l’action de pouvoir les déployer de façon automatique. Nous employons ici le terme déployer au sens large. Par exemple, certains services vont demander l’ouverture de flux réseaux lorsque d’autres vont nécessiter de mettre en place des ressources IaaS ou PaaS. Dans les deux cas, nous parlons de déploiement.
  • La mise en accès d’outil destinés au monitoring de vos services. A terme, plus vous donnerez les moyens à vos usagers de comprendre ce qu’il se passe lorsque vos services sont utilisés, plus vous allégerez le travail des équipes ayant à charge le support de ces services. Cela vaut également sur les processus de déploiement. Il est toujours plus productif de recevoir une information précise sur le pourquoi d’un échec que le célèbre : « ça ne marche pas ».
  • Les aspects de facturation associés à vos services. Il n’est pas recommandé aujourd’hui de ne pas fournir aux usagers la possibilité d’observer le coût de la consommation d’un service.

 

Les points ci-dessus vous aurons sans doute fait penser à ce que mettent à disposition les portails Cloud tels qu’Azure par exemple. Ce n’est pas une coïncidence, le Cloud étant la brique essentielle de la Digital Factory telle que définie jusqu’ici. Il ne faut donc pas hésiter à utiliser les facilités qu’offre cette plateforme pour vos besoins comme le Marketplace Azure ou le Private Marketplace. N’hésitez pas également à utiliser des outils de « ticketing » ou de gestion de processus IT pour encadrer les processus de déploiement ou de support des services.

Ces points techniques sont essentiels mais en aucun cas les seuls à prendre en compte. On pourrait parler encore des aspects de gestion de versions, de gestion d’environnements, de mise à disposition de ce catalogue via des APIs… De plus, nous avons abordé les points essentiels principalement du point de vue des usagers. En effet, les besoins du point de vue des fournisseurs de ces services sont également importants ; cependant, ils sont également fortement dépendants de contraintes technologiques et organisationnelles qui dépassent notre scope présent. Ce qu’il faut retenir, c’est que la concentration des efforts de vos équipes vers une expérience forte et cohérente pour vos usagers permet de mieux cadrer les besoins de vos équipes fournisseurs / propriétaires de ces services.

La mise en place d’un Catalogue de Services est une activité qui prends du temps et beaucoup d’itération. Mesurez vos efforts et automatisez uniquement ce dont vous avez la maîtrise.

 

 

Construire au sein de sa Digital Factory

 

Pour produire des initiatives devant être livrées en production, un certain nombre d’éléments sont nécessaires au-delà de la main d’œuvre et des financements. Nous parlons ici des aspects qui permettent aux équipes de pouvoir travailler de façon efficiente dans le respect des standards qui sont aujourd’hui établis dans notre industrie.

Dans un monde idéal, chaque équipe serait en mesure de choisir l’ensemble des outils lui correspondant le mieux. Cependant il faut rester pragmatique si l’on ne souhaite pas une explosion des coûts de licences en plus des coûts de maintenance. Quels que soient vos choix, il est fondamental de ne pas oublier ces aspects.

 

Gérer son initiative

 

Le besoin de suivi d’initiative dans le domaine de l’IT n’est pas nouveau. Énormément d’outils existent pour remplir ce besoin : Azure DevOps, JIRA, Basecamp

Quel que soit ceux que vous décidez d’utiliser, il faut garder en tête les besoins suivants :

  • Gestion des aspect itératifs des développements. Les méthodes itératives sont aujourd’hui le standard pour la gestion de projet, l’Agilité en tête. Votre maîtrise des aspects méthode doit être le premier prérequis lors du choix de votre outil. Trois questions sont essentielles pour encadrer votre choix :
    • Quel est le niveau de familiarité de vos équipes vers cet outil ?
    • Quel est le niveau d’intégration que vous souhaitez avoir sur les autres outils utilisés par vos équipes ?
    • Quelles sont les KPIs que vous jugez nécessaire pour le suivi de vos projets et la détection de problèmes lors de vos développements ?
  • Support des étapes de développement d’une tâche ainsi que son niveau de détail. Il est très important que l’équipe de développement soit en mesure de pouvoir exprimer le détail des tâches à travailler mais aussi, et surtout, de pouvoir représenter dans l’outil les étapes du processus de construction.
  • Support des besoins de communications équipe. La communication dans une équipe est importante. Les besoins de communication moyennement asynchrone (réponse en moins d’un jour) et directe sont souvent gérés par des solutions de chats comme Microsoft Teams ou Slack. Toutefois, nous recommandons, pour les décisions issues de ces discussions, les besoins asynchrones longs et les échanges pouvant servir de contexte à l’initiative, d’être centralisés dans cet outil.
  • Support des besoins de documentation. Tout élément de documentation doit être centralisé au sein de l’outil.
  • Rapport de suivi de projet. Produire l’ensemble des KPIs permettant de mesurer la performance de vos équipes est un vrai challenge si vous n’avez pas pris en compte ces aspects lors du choix de votre outil. Dans le meilleur des cas, l’outil que vous choisissez a la capacité de produire ce dont vous avez besoin, sans charge supplémentaire. Dans le cas où votre besoin est trop spécifique par rapport aux offres du marché, n’oubliez pas de regarder du côté de solutions tierces compatibles avec votre produit avant de vous lancer dans du développement spécifique.

 

Contrôle de source, plateforme de collaborations pour les développeurs

 

Là aussi, rien de nouveau, beaucoup de solution existent : Git, Mercurial, Bazaar, SVN

Toutes ces solutions présentent des qualités. Même si l’industrie aujourd’hui favorise clairement l’utilisation de contrôle de source distribué, Git en tête, des arguments peuvent être posés en faveur de chacune de ces solutions, sans prendre en compte des solutions plus confidentielles (comme Pijul) et/ou commerciales…

Cependant au-delà de ces solutions « bas niveau », l’élément déterminant est la solution qui va permettre aux membres d’une équipe de communiquer et de collaborer autour de bases de code conséquentes. Plusieurs solutions co-existent :

Au sein de votre Digital Factory, il est courant de pratiquer la mise à disposition du code source de vos projets au sein de l’organisation. Ces outils inclus s’intègrent donc avec les systèmes d’authentification présents au sein de votre organisation et fournissent une gestion des droits avancée pour l’accès au code source.

Plus que des moyens de contrôle de sources, ces outils constituent de vraies plateformes de collaboration autour du code source. Il est donc fréquent de les utiliser pour construire les artefacts à partir du code source mais également pour livrer ces artefacts dans les environnement techniques associés.

 

Gestion des artefacts de la Digital Factory

 

Nous avons évoqué plus haut des plateformes collaboratives qui permettent de construire les artefacts. Cependant, ces artefacts ont un cycle de vie qui leur est propre. Il est donc recommandé d’investir assez tôt dans une solution permettant de gérer ces artefacts comme il se doit. On parle souvent d’entrepôt d’artefacts. Dans l’idéal, chaque artefact construit doit être livré dans cet entrepôt d’artefacts.

Deux solutions font figure de leaders dans le domaine, principalement pour leurs aspects multi-technologiques :

A noter : les solutions évoquées plus haut peuvent également servir aux mêmes usages, la différence étant le niveau de spécialisation de celles-ci :

 

Avoir un entrepôt d’artefacts unique au sein de votre organisation permet de réduire les coûts de licences et les coûts de maintenance. Comme toute solution centralisée globale, elle requiert des efforts non négligeables pour assurer les niveaux de disponibilités requis et un niveau sécurité consistant. Cependant, ces aspects sont secondaires face aux possibilités offertes par la centralisation de vos artefacts (métriques d’utilisation facilement disponibles, mise en place de processus automatisés autour de vos artefacts…), sans parler encore une fois du coût et des aspects sécurité.

 

Livre blanc digital factory Cellenza

Tout savoir sur les Digital Factories

Vous souhaitez en savoir plus sur la mise en place et le fonctionnement d’une Digital Factory ? Nous vous invitons à découvrir tous les articles de cette série inédite :

 

 

Les experts Cellenza restent disponibles pour échanger sur vos projets de création de Digital Factory : contactez-nous dès à présent !

Nos autres articles
Commentaires
Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.