Avant l’agilité, c’était clair : je disposais d’une série d’outils d’analyse que j’appliquais sur mes projets en fonction des problèmes rencontrés.
Quand un sujet apparaissait, je définissais une démarche de traitement, je l’appliquais ou la faisais appliquer. Je la pilotais. Je rendais compte. Et en cas de besoin je faisais évoluer la démarche. De plus comme j’étais quelqu’un d’attentif au sort de mes congénères, je faisais attention à chacun et je mâtinais nos travaux d’explications, d’entretiens personnalisés, pour vendre, adapter les solutions trouvées à chaque problème. Régulièrement, j’organisais des séminaires pour mobiliser les équipes, organiser les médiations nécessaires avec nos clients, bref faire progresser tout le monde dans le même sens.
Mon principal souci était de faire avancer les dossiers dont mon équipe était chargée. Et je rentrais chez moi le soir, le devoir accompli, ou en passe de l’être. De temps en temps, il y avait bien une crise à résoudre (problème de planning, de résultats, de politique, etc.), mais en général l’écoute, la patience et l’âpreté à chercher une solution en venait à bout.
Mais cela c’était avant l’agilité. Un matin, des « coachs agiles » ont débarqué et m’ont expliqué que ce n’était pas suffisant, qu’on pouvait faire plus :
Eux : dans une équipe de 25, quand seul le chef a le droit de réfléchir et les 24 autres seulement le droit d’exécuter les ordres et de ne pas déplaire au chef, on perd en efficacité !
Moi : pour autant je n’ai jamais été un dictateur que je sache !
Eux : oui, mais nos biais cognitifs nous amènent à tout ramener à notre petite personne, sans le savoir, il faut changer cela pour devenir un manager inspirant. Il vaut mieux 25 personnes qui réfléchissent ! On peut s’organiser pour y parvenir.
Moi : bon …
On m’a envoyé en formation où j’ai expérimenté la nouvelle démarche en jouant aux lego avec des gens que je ne connaissais pas. Ambiance de travail, gamification, bienveillance, empowerment, épanouissement personnel … sont devenus de nouveaux mots d’ordres. Tout manquement à la démarche était pointé du doigt.
Un coach agile est venu m’expliquer que je devais « changer de posture » : là où je m’évertuais à faire le médiateur pour aider (Lassie chienne fidèle !), je devais désormais donner de l’autonomie, changer le référentiel de travail, pour plus d’efficacité, et … accepter moi-même de perdre le contrôle.
Quel drôle d’idée : donner le pouvoir aux autres, leur donner la responsabilité, perdre la mienne, au point d’être challengé moi-même par mes propres équipes … Là résidait le secret de la réussite désormais !
Alors je m’y suis mis : j’ai donné les clés du camion aux collaborateurs, j’ai perdu le pouvoir de décision, mais j’ai mis en place des KPI pour pouvoir quand même suivre ce qui se passait dans les projets. Nous travaillons différemment, nous communiquons plus. Certains n’ont pas réussi franchement à s’y mettre, mais je ne désespère pas. De fait, il y a de l’émulation et des résultats probants.
Finalement, avant je savais à quoi je servais précisément, maintenant c’est un peu plus flou et je ne sais pas si j’aime ça, moi qu’on avait recruté pour ma capacité « à tout piloter ». Rien ne me semble plus jamais achevé. Et à un coach agile à qui j’en faisais part m’a répondu « done is better than perfect ». Il a réponse à tout ! …
Et puis, il y a eu comme un petit miracle, lorsque les collaborateurs ont dû bosser sur les projets, ils se sont finalement tournés vers moi. Loin de jeter le bébé avec l’eau du bain, tous mes outils d’analyse et mon expérience, que j’avais laissés de côté sont redevenus utiles pour aider mes collaborateurs et mes partenaires.
Dès lors j’ai compris, que foncièrement l’agilité offrait l’opportunité d’un regard nouveau. Et que tout nouveau que soit ce regard, j’avais toujours de la valeur ! Mieux, mon expérience, pour peu que je sache attendre le bon moment pour qu’elle soit utile, avait de la valeur pour les autres ! Là où je voyais mon « obsolescence professionnelle » surgir, j’apercevais tout d’un coup un formidable levier pour faire mieux réussir encore mes partenaires.
Lassie chienne fidèle avait retrouvé la maison !
David Couillard
PS : quelqu’un peut-il me dire comment organiser des ateliers d’innovation « on site » avec nos développeurs désormais tous à Bombay ?
L’expression « SI Agile » revient régulièrement dans les articles récents. Si son sens premier se comprend bien, quel est le rapport entre SI Agile et Entreprise Agile ?
Nous avons vu dans notre chapitre 1 que le terme « Agilité » était employé pour des moyens, des organisations, des méthodes et des techniques utilisés à différents niveaux dans l’entreprise. Mais rien sur le Système d’Information… Pour le SI, le terme de « flexible » semble plus approprié.
Définition du si « agile » ou « flexible » ?
La définition communément admise est un SI dont la capacité de « time-to-market » a été fortement accélérée.
On rajoutera à cette définition, 2 capacités supplémentaires :
Pouvoir réagir à l’inattendu : arrivée d’un nouveau concurrent (Exemple : Free Mobile pour la téléphonie)
Pouvoir s’adapter facilement aux évolutions métiers (réglementaire, uberisation, digitalisation) et exploiter les nouvelles technologiques (Cloud computing, Big Data).
Cette définition est calée sur les résultats attendus des projets agiles : accélération du Time-to-Market, réagir à l’inattendu et s’adapter aux évolutions en cours. Il est donc tentant d’utiliser le même adjectif « Agile » pour désigner les 2.
Pourquoi distinguer agilité de l’entreprise et flexibilité du si ?
Les projets / organisations / entreprises agiles ont besoin d’un SI qui leur permette de délivrer toute leur valeur ajoutée et notamment l’accélération du « time-to-market ».
A l’inverse, les travaux / investissements réalisés pour rendre un SI plus urbanisé et interopérable peuvent pousser l’entreprise à aller vers des projets agiles afin de profiter de tous les avantages de son SI et de rentabiliser ses investissements.
La mise en agilité de l’entreprise pousse à aller vers un SI flexible. Et réciproquement.
L’agilité de l’entreprise et la flexibilité du SI sont corrélés mais pas identiques. Pour étudier la dynamique entre les 2, il est préférable à mon sens de les distinguer : agilité pour l’entreprise et flexibilité pour le SI.
Comment construire un si flexible ?
Le SI s’est construit par accumulation de couches au fur et à mesure de son histoire. Malheureusement le SI résultat n’est pas naturellement flexible au sens où on le souhaite aujourd’hui. Le rendre flexible nécessite des projets et donc des coûts. Alors comment le construire ? Tout le SI doit-il être flexible ? Est-il possible de n’avoir qu’une partie du SI flexible ? Voilà des questions auquel un Architecte d’Entreprise doit être capable d’apporter son concours pour y répondre.
Retour d’Expérience : la tentative du Bi modal
La notion de SI bi-modal a été introduite il y a quelques années par le Gartner. Elle permettait de différencier 2 pans du SI et donc 2 vitesses de transformation différentes. Un SI flexible qui pouvait évoluer très vite pour des problèmes de concurrence, de stratégie commerciale et d’évolutions des clients et des technologies. Et à l’opposé, un SI non flexible, qui pourrait évoluer à une vitesse moindre car il ne serait pas soumis à ces pressions de « time-to-market ». Le problème de cette analyse était qu’elle opposait le front office (la partie distribution / commerce) avec la partie back office (mainframe souvent), en oubliant que les évolutions du premier avaient des impacts sur le second et donc que leur évolution devait être conjointe.
Une réflexion souvent entendue : « je peux bien faire des évolutions sur mon Front client tous les 15j mais quand je demande une évolution sur le mainframe (ouverture d’un flux) il faut 3 à 6 mois de délai »…. Cette notion de SI Bi-Modal a depuis été revue par ses concepteurs
Le SI des sociétés est composé de plusieurs parties qui peuvent évoluer à différentes vitesses grâce aux travaux menés par les architectes et les urbanistes. Ils ont préconisé la mise en place des systèmes d’échanges, des référentiels etc. Le couplage faible et l’interopérabilité entre les différentes parties du SI prennent maintenant tout leur sens.
Le SI est multiple et composite. Ses contraintes et interactions autant internes qu’externes, sont nombreuses et variées. C’est dans l’étude de ses différentes dimensions que nous allons pouvoir dégager des idées pour le rendre plus flexible.
Rendre à la fois toute l’entreprise agile et tout le si flexible?
Certaines entreprises ont lancé de grands programmes de transformation afin de rendre l’ensemble de l’entreprise agile et de rendre le SI flexible (Axa par exemple). Cette révolution est liée au besoin de transformation digitale, à la concurrence des start-ups (Uber, AirBnB) et des GAFA.
Quand cette transformation est impulsée par la Direction (métier pas uniquement la DSI) sur l’ensemble de l’entreprise, cela engendre un changement de culture global de l’entreprise. La mise en agilité est alors facilitée par les moyens mis en œuvre au niveau des directions, des métiers et de l’IT.
On retrouve néanmoins dans ces plans de transformation les 2 dimensions :
Changement de culture d’entreprise et de méthodes pour aller vers l’agilité de l’entreprise
Fortes évolutions architecturales et investissements pour rendre le SI flexible.
Pour des facilités de communication, les 2 sont alors identifiés sous le terme « Agilité ».
Mais cela n’est pas toujours possible, pour des raisons de budget, de culture d’entreprise, de technologie etc. Avant de lancer un tel programme, il peut être intéressant de ne rendre qu’une partie seulement de l’entreprise agile ou une partie du SI flexible. Cela permettra de tester et de valider la démarche avant de la déployer à l’échelle / sur tout le périmètre.
Un si flexible est un si opérationnel bien architecturé et une usine logicielle en place
Pour que le SI soit flexible, 2 axes sont à prendre en compte :
Le SI opérationnel doit être construit sur des bases solides. Ces bases sont connues : points de référence identifiés pour les données, pas de redondance applicative, couplage faible et interopérabilité entre les applications / services / domaines, Maitrise des flux etc.. Les grands principes de l’urbanisation des SI sont bien présents.
La mise en place « d’usines logicielles » permet l’accélération effective du « Time-to-market », pour développer, tester, recetter et mettre en production (devops – du développement jusqu’à la maintenance) dans les meilleurs délais les applications dans le SI opérationnel.
L’usine logicielle est bien un des moyens qui permet de construire et de mettre en place un SI opérationnel répondant aux critères de la flexibilité.
Traditionnellement les architectes interviennent sur la 1ère composante, le SI Opérationnel. Pour des raisons de cohérence d’ensemble, les architectes pourraient aussi avoir un œil sur la mise en place des usines logicielles.
Quelques outils autour du DevOps … qui ont besoin d’architecture
De l’intérêt de la vue d’ensemble du si et de l’architecture
Pour comprendre le SI opérationnel, il faut en avoir une vue d’ensemble et voir ainsi qu’elles sont les parties qui sont plus « étanches » ou « indépendantes » les unes par rapport aux autres. Celles qui peuvent (éventuellement) évoluer indépendamment d’autres parties.
La cartographie du SI est un point d’entrée essentiel de cette analyse. La cartographie doit prendre en compte plusieurs dimensions du SI : fonctionnelle, technologique, flux et données principalement. Mais peut aussi prendre en compte les processus, la finance, les utilisateurs …
Comme on l’a vu, il faut que cette analyse prenne en compte obligatoirement la dimension métier dans sa transversalité par rapport au SI, car c’était bien le défaut initial du SI bi-modal.
Si flexible sur quel périmètre et pour quels critères ?
Dans la réflexion, il est essentiel de bien réfléchir aux 2 aspects du SI que nous avons déjà identifiés : l’usine logicielle et le SI opérationnel pour garder une vue d’ensemble du SI et de sa construction.
Ci-dessous, nous proposons une base de questions pour identifier un périmètre d’amorce de flexibilité du SI :
Définir le rythme des évolutions demandées, le « time-to-market » : Des évolutions rapides demandées avec des livraisons régulières ? Alors la flexibilité s’impose pour cette partie du SI.
De nouveaux projets ? De nouveaux terrains à défricher ? Il faut en profiter pour mettre en place une nouvelle architecture SI et une usine logicielle adaptée. Attention toutefois à bien définir le périmètre du projet : un périmètre trop restreint ne permettra pas de démontrer les bénéfices et un périmètre trop large aura des risques de rejet.
Profiter des innovations technologiques ? Bien sûr mais attention aux risques liés aux nouvelles technologies et leur pérennité notamment.
Quel périmètre métier ? Distribution ? Cœur de métier ? ou au contraire fonction support ? L’efficacité, le besoin métier, le risque opérationnel mais aussi les facteurs humains doivent rentrer en ligne de compte du choix de périmètre
Il est important, dans ces phases, de faire intervenir les architectes d’entreprise pour garantir la cohérence globale du SI et donc sa future flexibilité.
Construire un SI flexible est un vrai challenge. Souvent lié en plus à un changement de culture avec l’agilité en point de mire.
Par leur connaissance globale du SI et les projets transverses qu’ils peuvent identifier (référentiel, systèmes d’échanges, interopérabilité etc.), les architectes peuvent aider l’entreprise à rentrer dans ce nouveau monde de l’entreprise agile et de son SI flexible.
L’agilité défend 4 valeurs principales. Dans certains cas, on constate des équipes dites agiles mais qui ne sont plus en phase avec les valeurs. Pourquoi ?
En quoi les valeurs de l’agilité et de l’architecture devraient-elles se rejoindre ?
Les 4 valeurs de l’agilité
L’agilité se base sur 4 grandes valeurs qui sont tirées du Manifeste Agile, complétées par 12 principes.
Des valeurs et pas des dogmes
Pour commencer, rappelons que ce sont des valeurs et non des règles. Cela signifie qu’il s’agit d’une vision partagée, chacun ayant la liberté de décider des mécanismes à mettre en place pour y arriver.
Ces valeurs présentent une nouvelle façon de faire, par opposition à l’ancienne.
En effet, quand la valeur prône « la collaboration avec les clients plutôt que la négociation contractuelle », cela ne veut pas dire la mort de tous les contrats. La contractualisation à outrance a eu tendance à éloigner les gens, à les faire se retrancher derrière des clauses comme derrière des barrières infranchissables. La nouvelle façon de faire met en avant la collaboration, le partage d’information, la confiance comme des moyens d’avancer plus efficacement. Les contrats existent toujours mais sont faits différemment, sur d’autres bases.
A l’identique de ces valeurs, pour l’Architecture d’Entreprise, un Framework comme TOGAF pose les bases et bons principes de comment faire de l’Architecture d’Entreprise. Chaque entreprise doit s’approprier ces principes, les décliner dans son contexte et les appliquer suivant sa culture et sa maturité. Il ne s’agit pas d’appliquer l’intégralité du Framework sans une réflexion préalable.
Pour illustrer à quel point les valeurs de l’Agilité peuvent être détournées par les projets ou sont mal comprises par des collaborateurs, j’ai choisi 2 phrases. Elles reviennent régulièrement dans la bouche de collaborateurs et elles nous montrent le chemin restant à parcourir pour la compréhension des bénéfices de l’agilité.
En agile, on ne fait pas de documentation !
Nous allons essayer quelque chose appelée
« Développement Agile »
Ce qui signifie qu’il n’y a plus de plannings et plus de documentation. On commence directement à programmer et à se plaindre
– Je suis content que cela ait un nom.
– C’était votre formation.
La valeur prônée par l’agilité est « des logiciels opérationnels plutôt qu’une documentation exhaustive ». Historiquement, les logiciels disposaient d’une documentation abondante (Spécifications générales, détaillées, etc.) qui n’était pas lue, peu utilisée, pas adéquate et très peu maintenue.
Le but principal d’un projet informatique est bien d’avoir un logiciel opérationnel qui répond aux besoins des utilisateurs. La documentation est un sous-produit du logiciel. Elle doit servir aux utilisateurs, aux personnes qui vont en faire la maintenance, etc. mais elle n’est pas un but en soi.
Beaucoup de projets « classiques » semblaient avoir oublié ce but et donnaient l’impression de livrer plus de documentation que de code à la fin des projets, un comble !
Qu’en est-il pour les projets en Agile ? Etant donné la proximité des participants, il n’est pas nécessaire de formaliser tous les échanges par de la documentation in extenso. Les échanges ayant lieu en direct, et verbalement, ils ont moins besoin d’être complètement décrits. Seul le résultat est conservé, les principales décisions, les règles métier et les choix faits. La documentation est réduite au juste nécessaire et une partie est parfois même stockée dans le code directement. Certains projets agiles en ont-ils profité pour ne pas faire de documentation du tout ? Possible. Les responsables des maintenances ont-ils été surpris de ne pas avoir autant de documentation qu’avant ? Fort probable. Que certains développeurs n’aiment pas faire de la documentation in extenso ? On les comprendrait presque. Mais la documentation ne s’adresse pas qu’aux développeurs. La documentation sur les choix métiers, les données et certaines règles de gestion peut avoir son utilité.
La bonne documentation est bien celle qui va servir par la suite et qui sera maintenue…
L’architecture ne fait que de la documentation ?
A l’inverse, les architectes ont souvent été « accusés » de ne produire que de la documentation. De ne produire que des règles et des normes, pas toujours facilement applicables, que le projet doit ensuite se justifier d’utiliser, ou pas.
Les projets penseraient même que l’architecture les contraint à remplir des dossiers et à passer par des comités qui ralentissent leur bonne marche. Que ces étapes coutent chers et n’apportent rien (ou presque).
Ce n’est bien sûr pas comme ça que nous concevons l’Architecture d’Entreprise. Elle se doit d’être au service et en accompagnement des projets. Leur fournir une aide et non être un frein.
Comme pour les projets, l’architecture doit être documentée utilement et sans excès. Elle apporte la vision d’ensemble du SI dont chaque projet a besoin. Il est essentiel de connaître les règles de construction, pourquoi elles ont été définies et pourquoi certaines dérogations ont été accordées… car la règle est la conséquence d’un besoin et la remise en cause de ce besoin doit remettre en cause la règle.
La bonne architecture est bien celle qui est opérationnelle et donc proche des projets…
Le problème avec l’agilité c’est qu’il n’y a pas de planning
Avant de de faire notre business plan pour l’année prochaine, regardons comment nous avons réalisé celui de l’année passée.
Finalement, nous n’avons rien fait de ce qui était prévu. Comme les autres années
– Pourquoi fait-on l’exercice alors ?
– Cela n’aurait aucun sens de de ne pas avoir de plan
La valeur prônée par l’agilité est « l’adaptation au changement plutôt que le suivi d’un plan ». Avant, le plan était roi et devait être suivi, parfois jusqu’à l’absurde. La planification « à la soviétique » (détaillée sur 5 ans et sans changement possible) en était la parfaite illustration.
Maintenant et dans un monde qui change si vite, les projets doivent s’adapter à l’évolution des besoins et des exigences. Plus question de faire des projets avec des « tunnels » de plusieurs années. Plus question de s’entendre dire, les spécifications sont validées, plus rien ne peut changer avant la prochaine version, l’année prochaine au mieux.
Pour autant et pour des besoins de cohérence et de synchronisation entre les livraisons des produits, il est essentiel d’avoir une certaine visibilité sur les projets. Une vision détaillée à court terme et une vision plus globale à moyen / long terme (les notions de court et moyen terme restent à adapter à chaque situation) sont nécessaires. Des outils agiles existent pour réussir à se projeter sur ces échelles de temps, comme le Burn-Up Chart par exemple. Ils utilisent les données issues des itérations complétées pour alimenter des éléments de pilotage permettant de prendre des décisions.
Car les plannings doivent servir à dégager des trajectoires et des orientations sur le long terme. Ils rendent possible la synchronisation entre les différentes évolutions en cours dans le SI.
Les architectes font des plannings sur 5 ans qui sont irréalisables
Les architectes d’entreprise, garants de la vision d’ensemble du SI, se doivent de dégager une trajectoire globale, long terme, du SI. Ce faisant, ils donnent parfois l’impression de figer les évolutions à plus court terme. Tout semble déjà prévu d’avance et sur 5 ans ! Il semble ne plus y avoir de place pour de nouvelles initiatives ou pour des changements. Les projets ont alors l’impression d’être mis devant le fait accompli et de devoir respecter des échéances qui leur sont imposées sans concertation.
C’est une vision de l’architecte que nous ne partageons pas du tout.
Oui, l’architecture d’entreprise doit bien dégager une vue d’ensemble sur le long terme et essayer de « mettre en musique » les différentes évolutions du SI. Pour autant, il n’est pas question de figer cette trajectoire et de ne pas être en capacité de réagir à court et moyen terme aux événements qui ne manqueront pas de survenir.
La cible du SI ainsi que sa trajectoire sont nécessaires pour consolider les évolutions, donner de la visibilité et apporter de la transversalité. Mais ils doivent être adaptés dès le départ aux contraintes projets et être revus régulièrement en fonction des avancées des projets et de tout ce qui peut avoir un impact (stratégie de l’entreprise, concurrence, avancement / retard des projets, technologies etc.).
La trajectoire du SI constitue un outil d’aide à la décision, d’une part en démontrant que l’évolution du SI répond aux enjeux métiers et d’autre part en mettant en évidence les dépendances entre les différents projets.
Le détournement des valeurs de l’Agilité, nous ramène aux reproches qui sont faits aux architectes : trop ou pas assez de documentation et de normes, trop ou pas assez de planification.
Certains sont trop loin des réalités et d’autres trop proches ?
La convergence de l’architecture et de l’Agile vers un (juste) milieu de documentation et de planification semble donc la solution permettant à chacun d’avoir les outils nécessaires.
Parlons-en et travaillons ensemble seront les maîtres mots des prochains chapitres.
Suite de la série : les solutions arrivent
Chap 3 : Comment l’architecture d’entreprise doit-elle aider à « agilifier » le SI ?
Chap 4 : Comment les architectes (d’entreprise mais aussi les autres) peuvent interagir avec l’agilité ?
Processus, ce terme a fait le buzz en entreprise dans les années 1990 et 2000. La démarche associée promettait de casser les silos organisationnels et y est parvenu dans bien des cas : entreprise horizontale, entreprise en réseau, etc. Aujourd’hui l’approche processus, si elle n’est pas battue complètement en brèche par les démarches agiles, trouve encore une place comme outil d’analyse et de capitalisation de l’organisation.
Les spécialistes de l’agilité portent leurs critiques non sur l’approche processus elle-même, mais surtout sur la façon dont elle est mise en œuvre. En effet c’est bien souvent une démarche centralisée qui est déployée : « nous pensons (les processus) et vous les exécutez». De fait, cela est contraire à l’état d’esprit agile qui cherche à promouvoir la responsabilisation des collaborateurs, à faire rechercher par les équipes des solutions aux problèmes qu’elles rencontrent, etc. Notons bien au passage que dans une telle démarche, le management intermédiaire aussi se trouve dépossédé d’une partie de son leadership. Son rôle est réduit au contrôle de l’exécution des processus.
Quand, dans une organisation basée sur un management par les processus, des modes de management agiles sont déployés sans adapter l’approche processus, on aboutit à des situations schizophrènes, comme l’illustre l’exemple ci-aprèsdans une société de distribution automobile :
La satisfaction client est régie par une série de processus sciemment optimisés à appliquer en fonction des cas. Conscient que c’est insuffisant, la Direction des Ventes demande aussi aux collaborateurs en contact avec les clients de prendre des initiatives lorsque c’est nécessaire. Bien entendu, ces initiatives contreviennent parfois aux consignes prescrites par les processus. Au bout du compte, quand la satisfaction client est bonne (notée par le client via un questionnaire), tout le monde en est gratifié. Cependant, si le client montre une insatisfaction il est reproché au collaborateur soit de n’avoir pas suivi le processus s’il a pris des initiatives, soit d’avoir trop servilement collé au processus …
…c’est bien ce qu’on appelle une situation absurde ! Patatra !
La situation décrite ci-dessus est fréquente et symptomatique des grandes organisations. Il faut être vigilant à ne pas mettre en place des systèmes de management à « injonctions contradictoires », qui conduisent toujours à un retour en arrière (injustice, stress au travail, démobilisation, etc.).
Pour notre part, nous préconisons un usage de la démarche processus qui soit compatible avec les démarches de management agile.
Facilitation graphique – Lean Process
OUI à l’approche processus, lorsqu’elle permet dans un atelier de travail de faire émerger des solutions pour résoudre les problèmes rencontrés par une équipe. L’élaboration du processus en équipe permet aux collaborateurs de se mettre d’accord autour d’un schéma de fonctionnement commun.
Communication
OUI à l’approche processus lorsqu’elle permet d’incarner l’organisation et de porter un message dans les entreprises de grande taille (beaucoup de salariées) ou en forte croissance (beaucoup de clients). Le schéma du processus porte la structuration des activités.
Digitalisation
OUI à l’approche processus lorsqu’elle permet d’identifier les procédures à automatiser (« si c’est processable, c’est automatisable ») tout en expliquant le rôle conservé par les opérateurs.
OUI à l’approche processus lorsqu’elle permet de bâtir le parcours client de designer l’UX (User eXperience) et de s’assurer de la pertinence de la solution, afin d’éviter de déployer des processus défectueux. In fine elle permet de faire dialoguer le Marketing, la DSI et les Directions métiers.
OUI à l’approche processus lorsqu’elle permet de capitaliser les schémas de fonctionnement implémentés (repliés) dans les outils et ainsi de faire face au turnover des équipes. Le schéma du processus est utile pour les équipes informatiques et pour les opérationnels devant résoudre les problèmes rencontrés par leurs clients.
NON à l’exécution aveugle des processus qui bloque l’innovation et bride la performance.
L’agilité redessine les contours d’une démarche processus qui soit un outil au service de la performance. Les initiatives de digitalisation sont une formidable opportunité de rebattre les cartes des modes de fonctionnement opérationnels.
Le service Cloud d’Amazon, AWS, a été victime récemment d’une panne majeure de son service de stockage simple nommé S3. Cette brique technique est très populaire et répandue pour implémenter des applications ou services hébergés chez AWS. Pour vous donner une idée de l’ampleur de son utilisation depuis son lancement en 2006, ce service permet aujourd’hui de stocker des dizaines de milliards d’objets. D’autres briques techniques chez Amazon peuvent s’appuyer sur ce stockage pour fonctionner comme le service Elastic Compute (EC2), Elastic Block Shop et Lambda. Cette panne de service a eu donc pour effet d’engendrer des perturbations majeures pour plusieurs applications hébergées chez AWS :
La messagerie instantanée Slack
Le service de stockage en ligne Box
Le service de livraison des pizzas Dominos
Les sites web communautaires Reddit et BuzzFeed
Heureusement la cause de l’incident a vite été repérée et corrigée par l’hébergeur. En revanche, elle a tout de même engendré des indisponibilités de plusieurs heures pour certaines de ces applications. Est-ce que les entreprises ayant pris la décision de faire appel à du Cloud Public doivent pour autant entrer en mode panique et rapatrier leurs applications et données chez eux ? La réponse est NON bien entendu. Amazon a rapidement communiqué que la nature de la panne du service S3 était due à une erreur humaine déclenchée par un employé ayant toutes les autorisations et qui aurait soumis une commande manuelle avec de mauvais paramètres. De plus, l’impact de la panne se limitait uniquement au « datacenter » de la région Virginie située sur la côte Est des Etats-Unis. Une telle erreur aurait pu donc se produire n’importe où, chez n’importe quel fournisseur d’hébergement y compris dans vos propres « datacenters ».
Cet incident nous rappelle seulement qu’il ne faut pas se fier uniquement à la résilience de la couche infrastructure Cloud, même chez le leader du marché, pour garantir une haute-disponibilité. Il est bon de rappeler ici que les engagements de service (SLA) pour la brique S3 ne sont que de 99,99%. Ceci signifie tout de même une indisponibilité potentielle de 87,5 heures pour une année ! Le fournisseur de service de vidéo en ligne Netflix est aussi hébergé chez AWS et il a pourtant été épargné par la panne du service S3. Une étude réalisée en interne en 2014 avait permis d’estimer une perte de 200 000$ de chiffre d’affaires pour une heure d’arrêt de la plateforme. Nous pouvons donc estimer qu’en 2017 le coût total d’une panne de 4 heures aurait pu leur coûter plus d’1 million de dollars. Ceci est sans compter l’impact négatif sur la réputation et image auprès de leurs usagers qu’une telle panne aurait pu occasionner . En tenant compte de ces besoins, les architectes techniques de Netflix ont conçu une architecture cloud résiliente basée sur plusieurs zones AWS. Ceci leur permet donc d’éviter toute perte de service en cas de panne ou incident et d’avoir un meilleur SLA que les 99,99% promis par le fournisseur.
L’impact financier de l’arrêt de votre application métier est probablement moindre que celui de Netflix. Vous n’avez peut-être pas non plus un fournisseur Cloud ayant plusieurs « datacenters » dans différentes régions comme peut l’offrir AWS. Pour autant déployer vos applications sur du Cloud Computing ne vous affranchit pas du tout des services d’un architecte technique, au contraire ! Celui-ci, s’il déroule une démarche prenant compte des besoins métiers et des exigences non fonctionnelles, saura vous proposer des scénarios d’architectures résilientes. L’architecture finale sera plus chère et complexe sans doute. Il ne faut pas oublier dans ce cas d’estimer l’impact et la probabilité d’une perte de service avant d’évaluer si ces coûts supplémentaires en valent la chandelle.
Sources d’information pour incident AWS S3 survenu en mars 2017 :
Déployer des applications Saas sur Cloud Public est devenu très populaire chez certaines Directions Métiers en France. Tout ceci pourrait être amené à changer avec la nouvelle directive Européenne (GDPR) sur la protection des données personnelles qui entrera en vigueur en 2018. En effet cette réglementation exige une très forte gouvernance des fournisseurs hébergeant ces données. Le risque de recevoir une pénalité de 4% de son chiffre d’affaire mondial en cas de non-conformité pourrait donc inciter certaines Entreprises à demander à leur DSI de reprendre l’initiative.
Ce n’est donc pas un hasard de calendrier si l’ANSSI (Agence Nationale de la sécurité des systèmes d’information) a créé conjointement avec son homologue allemand (BSI) un nouveau label nommé European Secure Cloud (ESCloud). Une première version du référentiel des exigences a été publiée en décembre 2016. Elles couvrent les aspects suivants :
Mener une politique de sécurité en regard d’analyse de risques. Celle-ci devant être faite périodiquement pour une même application.
Avoir un responsable de sécurité de l’information, un responsable de la donnée personnelle et un responsable de la sécurité physique de ses installations.
Avoir un plan de sensibilisation à la sécurité au niveau ressources humaines : charte éthique, formation, gestion et capitalisation de la connaissance.
Avoir une politique de contrôle et droits d’accès pour ses bâtiments et certaines zones plus sensibles.
Avoir une cartographie de son SI au niveau infrastructure à jour.
Encrypter les données sensibles et chiffrer les flux. Hacher les mots de passes pour ne pas qu’ils soient accessible en clair.
Avoir une politique de sécurité pour prévenir et surveiller les failles: journaux d’évènements horodatés, analyse du code source si possible, tests d’intrusion fréquents, …
Avoir une politique de gestion des incidents de sécurité y compris de manière préventive.
Avoir une convention et un respect des engagements avec les sous-traitants participants à la mise en œuvre du service.
Garantir une localisation, un traitement des données et une gestion des opérations du datacenter au sein de l’Union Européenne.
Autoriser un organisme certifié par l’ANSSI à venir l’auditer et vérifier le respect de ses exigences.
Pour ceux qui douteraient de l’importance d’avoir un fournisseur de confiance, voici quelques chiffres 1 :
81% des entreprises françaises se sont dit victimes d’une cyberattaque en 2015.
Se remettre d’une violation de sécurité coûte en moyenne 800 000€.
9 semaines sont nécessaires en moyenne pour corriger une faille de sécurité.
35% des incidents de sécurité auraient été généré (parfois malgré eux) par les collaborateurs de l’hébergeur de ces données.
La plupart de ces exigences étaient déjà incluses dans les principales normes de sécurité reconnues par le marché : ISO-27001, SOC1, SOC2, CSA-CSM. L’effort à fournir pour obtenir ce label (GDPR) est donc faible pour les fournisseurs qui avaient déjà obtenu les principales certifications. C’est cependant une bonne chose d’avoir créé un label Européen pour rassurer les entreprises du vieux continent. En effet, que veulent les Directions Générales et les DSI ? Avoir l’engagement que le fournisseur de l’hébergement pourra assurer la sécurité de leurs données et que celles-ci ne vont pas se retrouver aux mains d’un concurrent, d’un gouvernement étranger ou d’une organisation malveillante. Ces entreprises veulent maîtriser le droit d’accès à ces données et ont besoin de partenaires qui accepteront d’être transparents et de partager la responsabilité de conformité sur la protection des données.
Au moment où nous rédigeons ces lignes, seuls 3 fournisseurs de services cloud ont fait la demande du label. Cependant il est fort à parier que tous les principaux acteurs du marché tenteront à moyen terme de décrocher ce précieux Graal qui leur facilitera l’accès au marché des entreprises européennes. Les entreprises françaises utilisaient jusqu’à maintenant très peu le Cloud et principalement pour du stockage ou des services de messagerie en mode SaaS. La plupart d’entre elles mettaient en avant les risques liés à la sécurité comme frein à son utilisation. L’obtention de ce nouveau label Européen est donc un pas en avant pour permettre de gagner la confiance des décideurs.
Pour conclure, il est fort à parier que nous devrions observer une hausse de part de marché des offres IaaS et PaaS sur Cloud Privé et voir une baisse de celui sur Saas déployé sur Cloud Public. Les DSI n’ont plus d’autre choix que de reprendre le contrôle de ces environnements. La part de « Shadow IT » dans les entreprises devraient donc diminuer aussi significativement. Le risque de recevoir une pénalité de la CNIL étant trop grand en cas de non-conformité à la GDPR.
1 : D’après l’article « Cybersécurité : Cinq chiffres clés à connaître »
