D’ailleurs, s’il y a bien une chose que vous devez protéger, ce sont bien vos administrateurs !

Qu’elles concernent les méthodes d’authentification, les permissions des applications tierces via les API (en autorisant une application tierce à synchroniser des données avec un service de stockage externe par exemple) ou encore la modification des politiques de rétention, Une action d’administration peut considérablement affecter les données et la sécurité du tenant à plus large échelle. S’il est nécessaire d’expliciter encore ce point, un Administrateur général (ou Global Administrator en anglais) a la capacité d’accéder à l’ensemble des données ou de gérer tous les paramétrages d’Office 365, Windows 10, d’Azure AD… mais également d’Azure !

Quelles fonctionnalités natives dans la plateforme de Microsoft ?

Quels modèles de droits au sein de Microsoft 365 ?

A ce jour, Microsoft 365 comporte deux niveaux de droits principaux. Ces deux niveaux permettent schématiquement de déléguer des droits d’administration en s’adaptant aux différents modèles d’organisations (petites / moyennes / grandes, centralisées / décentralisées) :

• Rôles Azure AD : Administration des services Azure AD et Microsoft 365 ;
• Rôles RBAC : Administration des objets au sein des services.

Premier niveau : Utilisation des rôles Azure AD pour gérer les services

La personne à l’origine de l’ouverture du tenant récupère automatiquement le rôle d’Administrateur Général. Il peut alors nommer d’autres administrateurs pour l’accompagner dans ses tâches. Dans la mesure du possible, les droits de Global Admin ne doivent pas être utilisés afin de limiter une surexposition des comptes d’administration. Une bonne pratique, consiste à limiter ce rôle général à un maximum de 3-4 comptes. De plus, pour la quasi-totalité des actions, il existe un rôle d’administration de service équivalent (ex : SharePoint Administrator, User Administrator, etc.).

Ces rôles d’administration de services sont également appelés rôles Azure AD. En effet, chaque service peut être vu comme une application Azure AD. Un administrateur serait ainsi équivalent au propriétaire du service en question. A l’heure de l’écriture de cet article, Microsoft propose 59 rôles différents, ce qui permet d’avoir un bon niveau de ségrégation des droits dans la plupart des cas.

Cependant, les rôles proposés par défaut donnent accès à l’intégralité du service administré pour l’ensemble du tenant et peut donner certains cas donner accès aux données sous-jacentes (notamment pour SharePoint Administrator, Exchange Administrator et User Administrator).

Figure 1 – Exemples de rôles sensibles

Dans le cas d’une maturité avancée, il est possible d’aller plus loin dans la ségrégation des droits en créant des rôles Azure AD personnalisés. Concrètement, cela revient à décider de quelles permissions bénéficie ce rôle (ex : « microsoft.directory/applications/create » permet de créer des applications dans Azure Active Directory).

Le revers de la médaille sera qu’il sera plus compliqué d’auditer l’administration et qu’il sera nécessaire de veiller à l’évolution des services afin de s’assurer que les permissions restent cohérentes avec les besoins des administrateurs.

Second niveau : Utilisation du modèle RBAC pour gérer les objets

Certains services tels que Exchange Online, Intune, les Centres de Securité et de Conformité ou encore Cloud App Security proposent des modèles de droits RBAC spécifiques.

Comme son nom l’indique, le Role Based Access Control (RBAC), permet d’implémenter une gestion des permissions plus fine ; avec la capacité de définir des rôles pour des périmètres définis (exemple sur certains groupes d’utilisateurs). Par exemple, il sera possible de créer « Helpdesk A » et « Helpdesk B » dans Exchange Online pour donner des droits de support à deux équipes distinctes sur un périmètre A et un périmètre B.

Comment provisionner les comptes d’administrations ?

La première question est de savoir comment créer l’identité d’un administrateur. Deux stratégies sont possibles :

• La création d’un compte dans le référentiel d’identité de l’organisation, qui sera ensuite synchronisé avec Azure AD (ex : wavestone.com) ;
• La création du compte directement dans Azure AD. Ce compte sera alors dit « cloud-only » (exemple : wavestone.onmicrosoft.com).

Quel que soit le rôle d’administration, il est recommandé pour un service SaaS comme Microsoft 365 que le compte se situe au plus près de la ressource administrée. Ici, cela revient à utiliser des comptes cloud-only. L’objectif est double : se prémunir d’une éventuelle indisponibilité ou d’une compromission du référentiel d’identité de l’organisation.

Comment attribuer des permissions ?

La deuxième question est de savoir comment attribuer les bons privilèges aux rôles d’administration créés.

Dans le cas de l’administration des services

Afin d’attribuer un rôle AAD, il est possible d’utiliser 3 méthodes (via le portail ou la commande PowerShell correspondante) :

• Le portail Azure (portal.azure.com) : c’est la méthode qui doit être privilégiée, car elle permet l’association de droits au plus près des ressources et l’utilisation de PIM, dont nous parlerons dans la suite de l’article ;
• Le portail Microsoft 365 (admin.microsoft.com) : il est possible de réaliser l’attribution des rôles directement à travers le portail principal d’administration. Cependant cette méthode n’est pas compatible avec PIM ;
• L’utilisation d’outils IAM tiers: ces solutions présentent aujourd’hui des connecteurs avec Office 365 pour réaliser le provisioning des identités et des privilèges. Ces solutions offrent une granularité moindre, ne sont pas compatibles avec PIM et sont source d’erreurs courantes. Par exemple, la synchronisation est généralement en sens unique, ce qui entraîne la réapparition du compte d’administration si celui-ci n’est supprimé que dans Azure AD.

A noter, il est également désormais possible d’assigner un rôle Azure AD à un groupe de sécurité (Cloud uniquement) via une fonctionnalité en preview. Cela pourrait simplifier certains modèles d’administration, dans lesquels l’équipe Communications Unifiées doit par exemple bénéficier du rôle SharePoint Administrator et de Teams Administrator. Attention cependant à la gestion de ce groupe.

Dans le cas de l’administration des objets

Pour les rôles RBAC, la définition des rôles se fait directement dans la plateforme d’administration du service concerné. Il est alors possible d’assigner le rôle en question manuellement ou à un groupe de sécurité, dans le portail ou via une solution IAM.

Figure 2 – Fonctionnalités natives de la solution

Comment bâtir et implémenter son modèle d’administration ?

Quelle stratégie pour définir son modèle de droits ?

La construction d’un modèle de délégation doit se faire sur le principe du moindre privilège. Le cœur du travail est faire l’inventaire des cas d’usages d’administration d’Office 365 et de faire la correspondance entre vos équipes et les droits disponibles.

Cela peut être l’occasion de remettre à plat l’organisation des équipes traitant de l’environnement de travail. Deux constats sont assez significatifs :

• Les terminaux mobiles et les postes de travail sont destinés à être gérés par des solutions unifiées (UEM) comme Intune, Workspace One ou MobileIron, et donc par la même équipe.
• Les outils de sécurité et de conformité sont de plus en plus intégrés nativement dans Office 365. Il est donc nécessaire de faire tomber le mur qui existait entre le monde workplace et le monde sécurité, afin de créer une équipe ayant la même ambition : créer et maintenir une plateforme maîtrisée et sécurisée.

Office 365 a pour particularité de rassembler une multitude de services différents, tels que le stockage de fichier ou d’informations (SharePoint, OneDrive), des outils de communication (Exchange, Teams) mais aussi de sécurité (Defender, Information Protection, etc.). Il est alors indispensable de regrouper les services en catégorie et de définir une matrice de correspondance entre équipe et rôles d’administration.

Concrètement, nous vous conseillons dans un premier temps d’utiliser les rôles Azure AD par défaut pour l’administration des services, et ensuite de définir des rôles plus granulaires avec RBAC et les rôles personnalisés.

Il est également intéressant d’identifier les rôles les plus sensibles, comme ceux permettant l’accès aux données ou paramètres de sécurité (par exemple : Global Admin, Exchange Admin, Security Administrator et Application Administration) afin de pouvoir adapter la sécurisation de ces rôles.

Comment déléguer des droits d’administration sur les objets dans un contexte multi-entité ?

Avant de parler sécurisation à proprement parler, se pose encore une autre question. Bien que la configuration des services et des paramètres de sécurité ne puisse se faire que centralement, les équipes locales ont besoin de faire actions de support : création ou modification d’un compte interne ou invité, réinitialisation des authentifiants, création de groupe Microsoft 365 ou d’une liste de distribution, etc.

Les rôles d’administration de services, les rôles Azure AD, n’offrent pas de ségrégation de privilège par périmètre ; un administrateur Exchange Online sera ainsi en mesure de manipuler l’ensemble des boîtes mails. Il ne sera pas envisageable de donner des dans des organisations complexes ou encore dans des contextes réglementés. Plusieurs stratégies sont disponibles, en fonction de la maturité et de la complexité de l’organisation.

Dans le cas de petites structures, le plus simple reste d’utiliser les fonctionnalités natives :

• Rôles RBAC: les rôles RBAC Exchange et Intune permettent généralement d’avoir le bon niveau de granularité pour gérer les objets dans les portails natifs ;
• Administrative Units: les Unités administratives, enfin en GA depuis fin Septembre, sont l’équivalent du RBAC pour Azure Active Directory. Elles prennent la forme de conteneurs dans lesquels un administrateur a la possibilité de créer ou de modifier des objets, ce qui trouve tout son sens pour les activités de support.

Dans le cas de structures plus importantes, la bonne pratique est de ne pas gérer les objets (utilisateurs, boites mail, groupes, sites SharePoint, etc.) directement dans les portails natifs. Il faut une interface permettant de gérer l’ensemble de ces objets, tout en tenant compte des logiques métiers et du modèle d’administration cible. Ci-dessous, trois exemples d’interface :

• Développement maison d’un « Custom Automation Engine» : cette interface sera décorrélée de de l’IAM et bien souvent une grosse machine à powershell / Graph API ;
• Intégration d’un connecteur à la solution IAM en vigueur afin de présenter une gestion complète des objets en faisant abstraction de leur hébergement direct ;
• Investissement dans une SaaS Management Plateform(SMP) : des éditeurs se sont spécialisés dans la création d’outil de gestion d’Office 365, mêlant fonctionnalités d’administration des objets, de gestion de licences ou encore de supervision sécurité et opérationnelle. Parmi ces solutions, encore peu connues, on retrouve notamment ManageEngine, CoreView et Quadrotech.

A noter : cette interface, dédiée aux équipes de supports, sera distincte d’une interface ouverte à tous les utilisateurs leurs permettant de créer centralement des utilisateurs invités, et des sites SharePoint, des Teams, etc. Concrètement, cette deuxième interface pourra être intégré aux outils de ITSM, à la SMP ou encore être développée à base de Power Apps et de Graph API.

Comment protéger l’accès à ces comptes

10 mesures pour sécuriser les comptes d’administrations

En fonction des licences de sécurité, principalement du bundle EMS, Microsoft fournit un certain nombre de contrôles pour sécuriser les comptes d’administration.

La plupart de ces mesures pourraient également être obtenues via des outils tierces.

Les mesures basiques de la sécurisation du compte d’administration

1. Un compte d’administrateur dédié

Un administrateur doit posséder un compte dédié à l’administration, différent du compte bureautique. Ce compte devrait être cloud-only dans la mesure du possible (ex : wavestone.onmicrosoft.com).

2. Authentification Multi-Facteur

L’authentification à plusieurs facteurs n’est plus une option aujourd’hui, et ce encore moins pour les administrateurs.

Cette mesure est disponible pour tous, pour toutes les licences :

• Via MFA pour Office 365 (également appelé MFA avec héritage par personne) qui force un challenge à chaque connexion ;
• Via les Security Defaults qui impose l’enregistrement d’un facteur additionnel pour tous les utilisateurs et impose le MFA pour les administrateurs à chaque connexion ;

Il est également important également de veiller à la désactivation des protocoles d’authentification héritée qui ne prennent pas en charge le MFA. Ces derniers permettraient en effet de passer outre l’authentification simple.

Il sera également pertinent de limiter les types de facteurs supplémentaires disponibles ; à quoi bon sécuriser les comptes d’administration si le second facteur est l’adresse Gmail de l’administrateur.

Des mesures de sécurisations fortement recommandées

3. Compte sans licence Office 365 

Sans licence, il se sera pas possible pour un administrateur d’accéder aux différents services et données de la plateforme, ou encore d’avoir une boite mail.

A noter, certains services, comme Power Apps ou Power BI, requièrent une licence pour accéder au portail d’administration. En pratique, il peut être intéressant de créer un groupe de sécurité attribuant les licences nécessaires pour les administrateurs.

4. Conditional Access (avec Azure AD P1)

L’accès conditionnel permet d’évaluer le contexte lors de l’accès à un service Office 365, et d’autoriser en fonction l’accès. Il permet par exemple de bloquer l’accès en fonction du type de poste utilisé (géré par l’entreprise ou non), du réseau sur lequel l’utilisateur est connecté, de l’application en question ou encore de son rôle d’administration.

Dans une logique Zero Trust, il ne faudrait pas différencier le réseau interne et le réseau externe, en particulier pour les administrateurs, mais plutôt se concentrer sur l’état du poste de travail et le risque de la connexion.

5. Protection de mot de passe (avec Azure AD P1)

Aure AD Password Protection apporte des contrôles sur les mots de passe. Il sera ainsi possible d’interdire l’utilisation d’un mot de passe courant ou d’un dérivé (avec une liste prédéfinie par Microsoft ou maintenue par l’organisation).

Une bonne pratique consiste à appliquer à minima cette protection sur l’ensemble des comptes d’administration Cloud-only.

6. Azure AD Identity Protection (avec Azure AD P2)

Azure AD Identity Protection permet d’ajouter une notion de risque dans l’évaluation des accès et des comportements des utilisateurs. Concrètement, il sera opportun des définir les politiques suivantes ;

• Risky users : Forcer le changement de mot de passe pour un administrateur susceptible d’être compromis (avec un risque Medium ou High) ;
• Risky sign-in : Forcer un challenge MFA lors d’un accès à risque (ex : IP anonyme ou inhabituelle).

7. Azure AD Privileged Identity Management (avec Azure AD P2):

Azure AD Privileged Identity Management est un service permettant de contrôler l’attribution et l’utilisation des rôles d’administration :

• Attribuer de droits « just-in-time » en donnant un rôle éligible au lieu de permanent ;
• Soumettre l’activation d’un rôle à une validation d’une tierce partie ;
• Mettre en place une date de fin de droit pour un rôle d’administration ;
• Forcer les recertifications des administrateurs.

Il sera pertinent de distinguer les rôles dits sensibles des autres, lors de l’implémentation.

Le suivi des administrateurs éligibles permet en bonus, de prendre conscience de l’utilisation réelle des droits d’administration et donc de nettoyer plus facilement la liste des administrateurs.

A noter, les fonctionnalités de PIM ont récemment été étendus aux différents groupes, ce qui permet de mettre en place du « Just-in-time » pour des cas plus exotiques comme les Super-Users RMS / AIP.

Pour aller encore plus loin

8. Supervision des action administrateurs pour détecter les comportements anormaux

Une fois toutes ces mesures de sécurisation en place, il ne vous reste plus qu’à implémenter de la supervision afin de détecter les non-conformités aux règles précédentes et les comportements anormaux.

Et pour cela, rien de mieux que de se référer à notre article sur le sujet pour comprendre les journaux disponibles.

9. Mettre en place une Privileged Access Workstation

L’administration étant une action par définition critique. Il est nécessaire qu’elle soit réalisée dans un périmètre de confiance. La mise à disposition de PAW, ou poste d’administration, permettra d’aller dans cet objectif.

La configuration du poste d’administration devrait être simple (pas de droits d’administration local, navigation Internet restreinte, ports USB bloqués, modules PowerShell préinstallés, etc.). Mais le fait de restreindre la connexion d’un administrateur Office 365 depuis ce poste peut poser plus de soucis. Pour cela, plusieurs possibilités existent :

• Dans un contexte moderne, une réponse simple est de s’appuyer sur les outils Microsoft : définir un profil de poste d’administration dans Intune et l’assigner aux administrateurs. Avec une règle d’accès conditionnel, il est possible d’exiger un poste conforme lors de la connexion.
• Dans un modèle plus classique, il est possible de mettre en place un silo d’authentification avec les administrateurs et les postes associés. On aurait ainsi un modèle se rapprochant du modèle en tiers bien connu des équipes AD.
• D’autre pistes sont également possibles, même si plus complexes : association d’un certificat et d’un reverse proxy ou encore d’un bastion.

10. Rester informé des bonnes pratiques et des nouveautés

On ne rappellera jamais assez qu’Office 365 étant une plateforme Cloud, elle est en évolution constante. Se tenir au courant permettra de continuer à augmenter son niveau de sécurisation au fil du temps.

Figure 3 – La sécurisation des comptes, des mesures qui se comptent sur les doigts de la main

Focus sur les comptes bris de glace

Une bonne pratique d’administration de la plateforme de Microsoft est la mise en place de comptes d’administrateur permettent en cas d’incident de récupérer le contrôle sur la plateforme.  Ce sont ce que l’on appelle des comptes bris de glace. Ces comptes doivent permettent un total contrôle sur le tenant Office 365 et le rôle de Global Administrator leur est donc attribué.

Ces comptes doivent faire preuve d’une sécurisation, cependant il ne faut pas oublier leur spécificité qui consiste à les utiliser en cas d’incident. Ainsi la sécurisation imposée à ces comptes doit rester compatible avec le caractère urgent de leur utilisation.  Ces comptes doivent donc répondre aux recommandations suivantes :

• Être des comptes cloud-only
• Pas de MFA configuré (ou du moins un MFA tiers)
• Stockage du mot de passe dans un coffre auquel seulement des personnes identifiées de l’équipe sécurité ou Office 365 peuvent accéder
• Mise en place d’alerte afin de vérifier que ces comptes ne sont pas utilisés hors d’une procédure d’incident nécessitant l’utilisation du bris de glace.

Il est également recommandé de ne pas utiliser de convention de nommage spécifique pour ces comptes, ils ne doivent pas attirer l’œil d’un possible attaquant !

Conclusion

La sécurité sur Office 365 repose sur des mesures techniques de protection des comptes administrateurs, ainsi que l’implémentation d’un modèle d’administration cible, ce qui comprend une gouvernance et des processus clairs, des outils pour mettre en place cette délégation de droits, et des dispositifs pour le maintenir dans le temps.

Mais quelles que soient les mesures de protection implémentées, la sécurité repose avant tout sur les administrateurs de la solution. Sensibilisation des administrateurs et contrôles seront indispensables.

Les administrateurs doivent garder à l’esprit que leurs comptes donnent accès à des informations et des actions extrêmement sensibles : ils sont donc la cible privilégiée des pirates informatiques !

O365 étant en constante évolution, chaque nouveauté introduite par Microsoft pourra amener également son lot de problèmes de sécurité qu’il faudra étudier et prendre en compte. Profitez-en pour mettre à jour vos documentations : analyses de risques O365, configuration des services, modèle de délégation…toujours sans oublier de permettre à vos administrateurs de se former !

Cet article Comment maîtriser l’administration dans Microsoft 365 ? est apparu en premier sur RiskInsight.

Un concept, plusieurs technologies

La virtualisation du poste de travail permet d’héberger et de gérer de manière centralisée un environnement de travail dans un datacenter, l’utilisateur y accédant à distance depuis n’importe quel terminal. Ce concept regroupe en fait différentes technologies :

• Le SBC (Server Based Computing), technologie historique, popularisée par Citrix en particulier, où les utilisateurs accèdent à un bureau virtuel « partagé »,
• Le VDI (Virtual Desktop Infrastructure), où chaque utilisateur dispose de son propre poste de travail sous forme d’une machine virtuelle.

Les solutions des éditeurs intègrent souvent les deux technologies. Les entreprises ont alors le choix de leur implémentation (le SBC étant plus économique, le VDI proposant une meilleure expérience utilisateur). Une autre possibilité est d’utiliser les solutions de DaaS (Desktop as a Service) où l’environnement de travail virtuel est délivré sous la forme de service Cloud.

Le sujet étant assez complexe, les entreprises doivent réfléchir à l’intérêt et à la manière la plus efficace d’appréhender et de mettre en œuvre la virtualisation du poste de travail.

Une approche stratégique de mise en œuvre massive

Certaines entreprises sont pleinement convaincues par les apports de la virtualisation du poste de travail : bénéfices en termes de facilité de mise à jour des postes et des applications, de rapidité et de souplesse de mise à disposition d’environnements, de sécurité… voire de baisse des coûts (ce qui est plus discutable). Elles décident donc de s’engager dans la voie d’une implémentation sur un périmètre très large.

Cette vision peut également être renforcée par les difficultés rencontrées lors de la migration de Windows XP vers Windows 7, avec la volonté de ne pas renouveler cette (douloureuse) expérience. Par ailleurs, la virtualisation permet réellement de répondre à des enjeux actuels de l’entreprise et des Métiers : sécurité, mobilité, rapidité de déploiement, soit autant d’arguments en sa faveur.

Un déploiement massif peut donc être un choix justifié mais il convient de ne pas se leurrer : il s’agit d’un choix fort et d’une véritable rupture par rapport au modèle de poste de travail traditionnel, tant pour les équipes IT… que pour les utilisateurs. Une implémentation massive est un projet long, complexe qu’il convient de ne pas sous-estimer.

Cette approche nécessite donc un travail important de cadrage, d’évaluation des intérêts sans nier les limitations connues (expérience utilisateur pas toujours satisfaisante, utilisation en mode déconnecté…). En particulier, la virtualisation n’est pas le remède miracle permettant de régler tous les problèmes de gestion du poste de travail. Les difficultés liées à la complexité de paramétrage de l’environnement utilisateur, de compatibilités applicatives restent ainsi les mêmes que sur un poste traditionnel. Au final, il s’agit de bien identifier les raisons pour lesquelles on souhaite s’engager dans déploiement massif. Des enjeux importants de sécurité constituent par exemple un bon argument.

Une approche tactique par les besoins et les cas d’usage

Une autre voie, moins ambitieuse (au moins dans un premier temps), est de définir dans quels cas la virtualisation peut être une solution appropriée. Il ne faut cependant pas tomber dans une vision purement technologique mais au contraire adopter une approche centrée sur les besoins et les cas d’usages.

Pour cela, la première étape consiste à faire un état des lieux fonctionnel et technique exhaustif de l’existant au niveau de l’environnement de travail et d’identifier les besoins. Cela peut combiner des besoins purement internes à la DSI (meilleure gestion des postes par exemple), des enjeux au niveau de l’entreprise et des Métiers (continuité d’activité pour des collaborateurs clés) et des cas d’usage (télétravail, travail en mobilité, BYOD…).Il est nécessaire à chaque fois de cerner précisément les enjeux, les attentes, les échéances et les gains escomptés.

Il convient ensuite d’étudier les solutions de virtualisation du poste de travail les plus adaptées aux différents besoins (SBC, VDI, DaaS). Cela nécessite une bonne connaissance du marché et des offres, d’autant plus que celles-ci évoluent encore très régulièrement, notamment les offres DaaS assez récentes. Des rencontres avec les acteurs du marché sont à envisager.

La confrontation des besoins et des solutions possibles doit permettre de faire émerger des opportunités d’utilisation de la virtualisation et des scénarios de mise en œuvre. Chaque scénario doit être évalué selon différents axes afin d’en valider la pertinence : l’intérêt, le périmètre couvert, les coûts, les délais, la complexité, les impacts techniques et organisationnels, la technologie la plus adaptée.

Les scénarios retenus doivent enfin être mis en regard les uns des autres afin de définir une roadmap globale de mise en œuvre selon les priorités et les échéances. Cette roadmap est souvent progressive, permettant de déployer les solutions sur des périmètres restreints, de valider leur fonctionnement et leur adoption par les utilisateurs, avant d’envisager éventuellement un déploiement plus important. Cette approche plus prudente s’avère néanmoins très pragmatique et plus agile à mettre en œuvre.

Quelle approche privilégier ?

Une approche tactique consiste à mettre en place la virtualisation du poste de travail de manière ciblée pour des cas d’usage et des besoins bien identifiés. Dans la plupart des cas, cette dernière semble être plus pertinente. Elle permet à la DSI de mieux anticiper les écueils de la virtualisation des postes de travail, d’affiner son offre de service, sans pour autant s’interdire un déploiement beaucoup plus important par la suite.

Cet article Virtualisation du poste de travail : quelle stratégie adopter ? est apparu en premier sur RiskInsight.

Un environnement aligné sur la stratégie de l’entreprise et les besoins Métiers

Le nouvel environnement de travail doit d’abord être pensé en lien avec la stratégie globale de l’entreprise. Dans certains cas, les innovations vont permettre d’améliorer voire de transformer les processus, dans le cadre de la digitalisation des entreprises par exemple. Dans d’autres cas, il s’agira plus prosaïquement d’optimiser les coûts (au moins dans un premier temps).

Charge à la DSI ensuite d’impulser une approche orientée métier et de devenir force de proposition quant à l’environnement de travail. L’objectif est bien de prendre un rôle de partenaire d’innovation sur ces sujets, afin de pouvoir anticiper les prochaines évolutions plutôt que de les subir. Cela implique un travail sur deux axes : d’un côté cultiver une proximité étroite avec les Métiers afin de cerner au mieux les usages et les besoins futurs ; de l’autre, développer une activité de veille et d’innovation pointue sur les prochaines évolutions technologiques.

La DSI doit néanmoins réfléchir avec quel Métier cela semble pertinent de proposer une telle approche. Elle peut par exemple se concentrer sur l’environnement de travail des utilisateurs réalisant le cœur de métier de l’entreprise, ou bien sur des Métiers amenés à se transformer profondément les prochaines années. Dans tous les cas, une partie des travaux réalisés seront bénéfiques à l’ensemble de l’entreprise.

La démarche peut être désormais lancée par la DSI en constituant avec les Métiers une équipe projet mixte et pluridisciplinaire qui va piloter la réflexion. Celle-ci va s’articuler autour de 4 étapes.

1 – Penser métier (et sans contraintes)

Pour comprendre les besoins actuels des utilisateurs et imaginer les usages futurs, il est essentiel de convier les représentants métiers à des d’ateliers de réflexion autour des processus métiers existants et futurs. Ils ont pour but de se focaliser sur les usages, indépendamment des possibilités technologiques, sans prendre en compte les différentes contraintes connues et imposées actuellement (légales, juridiques…). Il s’agit d’être créatif et d’éviter de se limiter. Une fois ces usages définis et ces processus entérinés, il est temps de se pencher sur les technologies.

2 – Penser innovation (et à long terme)

Pour cela, des ateliers avec les référents techniques de la DSI permettent d’identifier les technologies qui répondent à plus ou moins long terme aux besoins exprimés par les Métiers. L’environnement de travail impliquant de nombreuses couches du SI, il ne faut pas hésiter à solliciter de nombreuses expertises techniques de la DSI, du réseau au poste de travail en passant par la mobilité, le collaboratif…

Attention à ne pas se limiter ici aux technologies connues ou matures dans un avenir proche : il ne faut pas hésiter à raisonner à plus long terme (jusqu’à 5 ans) en incluant des technologies très innovantes, parfois encore en développement ou au stade de concept.

3 – Co-construire la roadmap d’évolution de l’environnement de travail

Il est alors temps de confronter besoins Métiers et technologies afin de bâtir une roadmap d’implémentation. Les technologies sont évaluées par rapport à leur niveau de maturité et à leur niveau de rupture. Les Métiers participent à la sélection des technologies à retenir par rapport à l’usage envisagé et à la plus-value qu’elles pourraient apporter. La roadmap a pour intérêt de prioriser dans le temps les technologies à implémenter par rapport aux besoins Métiers mais également leur niveau de maturité. Elle permet à la DSI et aux Métiers de disposer d’une base commune et partagée sur l’évolution de l’environnement de travail.

Un exemple concret de roadmap peut être donné pour un Métier comme celui de conseiller clientèle en agence. Il est aujourd’hui possible de mettre en œuvre des bornes interactives ou d’utiliser un QR Code sur le terminal mobile du client pour son identification à son arrivée dans l’agence. Imaginez : d’ici 2 ans, ces bornes pourront intégrer d’autres fonctionnalités comme la reconnaissance faciale ou biométrique, ce qui permettra de notifier le conseiller sur son poste de travail dès l’arrivée dans l’agence de son client. A horizon 5 ans, on pourra même envisager la mise en place d’assistant d’écoute qui présentera au conseiller de manière interactive sur son poste les fiches produits les plus adaptées au client selon la conversation.

4 – Décliner concrètement la roadmap… et la faire vivre

Une fois la roadmap définie, il convient d’en tirer profit ! Il s’agit dès lors de vérifier la faisabilité des pistes envisagées et les contraintes de mise en œuvre, tant réglementaires que techniques. Le meilleur moyen est d’adopter une approche pragmatique de type test and learn pour appréhender et évaluer au mieux les apports de ces innovations technologiques, leur maturité et leurs impacts sur le SI.

Mettre en place un espace de démonstration s’avère une bonne pratique. Il permet certes de tester concrètement les prototypes de l’environnement de travail de demain, mais il constitue également une vitrine technologique et un lieu d’échange autour de l’innovation entre la DSI, les Métiers, et même les utilisateurs finaux. Les retours sur ces expérimentations alimentent la roadmap, celle-ci étant mise à jour périodiquement en fonction des éventuelles réorientations Métiers et des évolutions technologiques. Un cercle vertueux peut alors s’enclencher permettant de pérenniser l’initiative dans le temps.

Une démarche bénéfique pour la DSI

Ce type de démarche s’inscrit complètement dans les orientations actuelles de la DSI, tendant à se rapprocher des Métiers et à être le moteur de l’innovation au sein de l’entreprise. Elle renforce le dialogue avec les Métiers et valorise également les travaux de veille technologique en leur donnant une orientation réellement opérationnelle.

La mise en place d’un laboratoire de démonstration sur les technologies environnement de travail apparaît alors comme un très bon vecteur de communication en direction des Métiers mais également des collaborateurs internes.

Cet article Réinventer l’environnement de travail de demain avec les Métiers est apparu en premier sur RiskInsight.

Après 9 mois d’existence, force est de constater que Windows 8 peine à convaincre le grand public. Pour les grands comptes, l’arrivée de Windows 8 suscite des réactions diverses.

Pour ceux qui n’ont pas encore fait le pas vers Windows 7, l’éventualité d’un passage vers Windows 8 a été écartée. Les raisons de ce rejet tiennent en deux points majeurs. D’une part, des surcoûts sont induits par la nouvelle interface utilisateur ModernUI, déroutante et nécessitant une conduite du changement renforcée. D’autre part, l’absence de support de la part des éditeurs et la faible visibilité sur sa mise en place génèrent un risque important pour la bonne tenue du planning.

Quant aux Grands Comptes ayant déjà déployé Windows 7 (ou qui sont en train de le faire), la plupart choisissent d’expérimenter Windows 8 auprès de populations nomades, majoritairement des profils commerciaux, en vue de les doter d’un terminal unique couvrant à la fois les usages de type poste de travail et tablettes (matériel dit « transformable »).

En effet, l’intérêt majeur de Windows 8 concerne le développement des usages mobiles et tactiles. Pour autant, si la DSI est enthousiaste à l’idée de gérer son parc de PC et tablettes de façon unifiée, la réaction des utilisateurs est quant à elle plus mitigée : en effet, les tablettes Windows 8 Pro restent encore à l’heure actuelle nettement plus lourdes que des matériels équivalents sous iOS ou Androïd.

Au final, les grands comptes ne se sont pas empressés pour adopter Windows 8. A l’heure où nombre d’entre eux accélèrent leurs chantiers de migration vers Windows 7 pressés par l’échéance de fin de support de Windows XP, seuls quelques-uns envisagent un déploiement tactique de transformables Windows 8 sur des populations ciblées.

Windows 8.1 : trois pas en arrière, un pas en avant

Fort de ce constat, Microsoft revient avec une nouvelle version : Windows 8.1. Cette version est marquée avant tout par une vraie remise en question des choix ergonomiques de Windows 8 : le bouton « Démarrer » est de retour, il est possible de démarrer directement sur le bureau et plus généralement de se passer complètement de l’interface ModernUI ! Il devient ainsi possible de « brider » le terminal pour lui donner une ergonomie beaucoup plus proche de Windows 7.

Les apports fonctionnels sont – quant à eux – plus mesurés. À noter toutefois la fonctionnalité de Workplace Join qui permet à un collaborateur d’intégrer ses devices personnels (smartphone et poste de travail) au SI de l’entreprise. Une fois joint, le device est reconnu en tant que périphérique personnel et peut se voir attribuer des accès aux applications de l’entreprise. De plus, il est possible de  synchroniser du contenu professionnel (Work Folders) directement sur le device personnel. Les données sont marquées comme étant du contenu professionnel, via une gestion des droits numériques (type DRM), et peuvent être effacées à distance par un administrateur.

Avec Windows 8.1, Microsoft cherche donc avant tout à répondre en urgence aux inquiétudes des grandes comptes déroutés par ModernUI. Et en cela Windows 8.1 atteint son but. Reste la problématique du support des applications et le form factor peu avantageux des matériels Windows 8 : sur ces 2 points, éditeurs et constructeurs progressent, et il est raisonnable de penser qu’à horizon d’un an, ces freins auront été levés.

Un nouveau cycle de vie…oui, mais lequel ?

Mais avec Windows 8.1, Microsoft inaugure aussi une nouvelle stratégie de mise à jour de son OS. Finis les services packs : Windows sera désormais revu complètement sur un rythme annuel.

Si l’intention de Microsoft est claire – aligner le rythme d’évolution de Windows sur celui des concurrents (Apple et Google) – la firme de Redmond n’a pour l’instant donné que peu d’éléments concrets permettant d’en appréhender l’impact sur l’organisation des DSI.

Or, cet impact pourrait être majeur. En effet les DSI ont jusqu’à présent fait évoluer leur parc de poste de travail par paliers (migration de Windows 2000 vers XP, de XP vers 7) opérés à l’occasion de migrations majeures tous les 6 à 7 ans et nécessitant des chantiers très lourds de design, d’inventaires, et de mise en compatibilité du parc applicatif.

Les DSI devront-elles demain être capables de conduire ces chantiers en continu ? Et donc pérenniser des activités qui aujourd’hui sont menées en mode projet ? Pourront-elles maîtriser le cycle de vie de leur OS ? Ou seront-elles « forcées » à suivre le nouveau rythme imposé par Microsoft ?

Là encore, les grands comptes s’inquiètent… et attendent de Microsoft des réponses claires avant de s’engager plus loin. Un point c’est tout.

[Article écrit en collaboration avec Arthur Georges, consultant]

Cet article Windows 8.1 : un point c’est tout ? est apparu en premier sur RiskInsight.