La boîte à idées - Le blog de Jean Chambard

Une des questions clés de la préparation d’un projet est : « combien le projet va-t-il coûter ? ». Chaque responsable de projet se trouve donc confronté à l’élaboration du « fameux » budget du projet, c’est-à-dire imaginer et chiffrer à l’avance la totalité des dépenses qui seront générées par le projet sur son cycle de vie, ce qu'on appelle communément la charge globale d'un projet.

La charge globale d’un projet est la quantité de travail à fournir pour conduire le projet, indépendamment du nombre d’intervenants au sein de l’équipe. La charge s'exprime en Jours Homme, Mois Homme, ou Années Homme, selon la taille du projet. Elle permet  de calculer et d'obtenir un budget projet, et de définir la taille de l'équipe de réalisation. Notons que cette charge globale se répartira ensuite par lot (ce qui permet éventuellement de sous-traiter un lot), par phase (conception générale, détaillée, développement, intégration, recette), ce qui permet de planifier le projet, d'affecter les ressources puis de le piloter et par tâche, ce qui permet au chef de projet de piloter ses ressources.

Voici quelques méthodes simples pour calculer cette charge globale et donc les coûts et délais associés. Nous supposerons que vous avez déjà effectué votre analyse de risque et définit votre stratégie de développement en conséquence (Méthode agile, Cycle en V, etc.) Mais d'abord rappelons quelques lois régissant ces calculs.

La loi de Hofstadter

La loi de Hofstadter est une loi empirique (comme la loi de Moore) énoncée par l'universitaire américain Douglas Hofstadter dans son œuvre, Gödel, Escher, Bach : Les Brins d'une Guirlande Éternelle (Prix Pulitzer 1980) et qui s'applique généralement bien aux projets logiciels. Cette loi affirme :

Selon cette loi, il vous faudra, pour mener à bien votre projet, plus de temps que prévu. Mais selon cette même loi qui fait appelle à elle-même en boucle récursive, même en tenant compte de ce fait et de l'intégrer dans vos calculs, il vous faudra quand même plus de temps que prévu.

En clair, cela signifie qu'il est difficile d'estimer correctement la charge d'un projet mais que plus vous chercherez à affiner votre estimation, et plus votre estimation sera fausse. On peut d'ailleurs rapprocher cette loi de la loi de Parkinson.

La loi de Parkinson

La loi de Parkinson - à ne pas confondre avec la loi de futilité de Parkinson - a été énoncée en 1958 par le professeur C. Northcote Parkinson :

Selon cette loi très empirique, si vous donnez 15 jours à une personne pour réaliser un travail qui prend normalement 10 jours, il lui faudra effectivement ces 15 jours.

Si donc vous estimez la charge de votre projet à 200 jours*homme, et qu'à cela vous rajoutez une marge permettant de gérer les imprévus (car selon la loi de Hofstadter ci-dessus, il faut plus de temps que prévu), disons de 60 jours*homme, votre équipe projet consommera les 260 jours*homme pour réaliser le projet, mais il vous faudra probablement encore 80 jours pour traiter les imprévus, ce qui confirme ainsi la loi de Hofstadter.

Une fois ces lois maîtrisés, vous pouvez passer à l'estimation du projet à proprement parler.

L'estimation d'un projet

L’estimation d’un projet informatique comprend quatre étapes :

1. Estimer la taille du produit à développer. Celle-ci se mesure généralement en nombre d’instructions (lignes de code) ou en points de fonction, mais il existe d’autres unités de mesure possibles.

2. Estimer la charge en mois hommes ou en jours hommes, à partir de la taille du produit.

3. Construire le calendrier du planning.

4. Estimer le coût du projet en monnaie locale

La première étape consiste donc à estimer la taille du produit à développer. Il existe pour cela quatre grandes méthodes.

• La méthode COCOMO (acronyme de l'anglais COnstructive COst MOdel). Conçue en 1981 par Barry Boehm, COCOMO est une méthode basée sur les résultats de 63 projets de développements informatiques (allant de 2 000 à 100 000 lignes de code). Elle se base donc sur des statistiques. Aujourd'hui, il existe également un modèle COCOMO II, prenant en compte la ré-utilisation des composants. Cette méthode ne peut s'utiliser que quand la phase de conception est déjà bien avancée, car il est sinon difficile de calculer correctement le nombre de ligne de code qu'il va falloir créer, modifier ou réutiliser.

• Les points fonctions. Cette méthode a été mise au point par Alan Albrecht en 1979 et se base=ait à l'origine sur quatre entités (entrée, sortie, interrogation, fichiers). Depuis 1984, on utilise entrées, sorties, interrogations, les groupes de données externes et les groupes de données internes, avec pour chacune de ces 5 entités un niveau de complexité simple, moyen ou élevé. Cette méthode se limite aux aspects strictement fonctionnels et ne prend pas en compte la complexité de réalisation, pas plus que les moyens humains, matériels et technologiques. Les exigences non fonctionnelles ne sont pas prises en compte non plus.

• Delphi : C'est une méthode élaborée en 1948 par la Rand Corporation et basée sur le jugement d ’experts. Le principe est de rechercher des analogies avec des projets antérieurs, et d’affiner successivement les ratios énoncés par plusieurs experts jusqu’à obtention d’une convergence entre tous les experts. Chaque expert donne son estimation de la charge projet ; tous les points de vue sont ensuite publiés de manière anonyme, puis chaque expert corrige son estimation initiale qui publie une nouvelle estimation et justifie son jugement avant de faire sa proposition définitive.

• La répartition proportionnelle. Cette méthode peut être utilisée pour calculer les charges de chaque étape, ou pour calculer la charge globale du projet à partir d'une estimation de la charge de développement du projet. Cette dernière peut être obtenue par analogie avec des projets antérieurs, comme pour Delphi. Une fois la charge de réalisation connue, il suffit d'appliquer de simples ratios.

Ainsi, si vous estimez que la charge de développement d'un projet est de 1.000 JH, alors la charge de l'ensemble des phases sera de 1.000 / 0,47, soit 2.128 JH environ. A cela il faut rajouter les charges transverses au projet : pilotage, gestion des environnements, etc. Là encore, il existe des ratios qui s'appliqueront sur la charge totale calculée précédemment :

Ce qui vous donnera la charge globale du projet (hors marge de risque ; cf. infra).

La seconde étape consiste à  estimer, à partir de la taille du produit, la charge en mois hommes ou en jours hommes. Si vous êtes passé par la méthode Cocomo ou par les points fonction.

La troisième étape consiste à calculer le temps minimal et le temps optimal de réalisation du projet. on estime que le temps minimal pour réaliser le projet est fonction de la racine cubique de la charge :

Tmin (exprimés en mois) =  2,5 * (charge en mois homme)^1/3 (exposant 1/3 = racine cubique)

Selon la taille de votre organisation projet vous pouvez minorer ou majorer le coefficient multiplicateur en prenant comme valeur 2 ou 3 au lieu de 2,5. Le délai optimum correspond au meilleur compromis entre délais, coûts et prise de risques.

Topt (exprimés en mois homme) = 1,4 * Tmin

La quatrième et dernière étape consiste à estimer les ressources optimales nécessaires à la réalisation du projet. Le nombre de ressources est fonction de la racine carrée de la charge en mois homme.

Nombre de ressources = (charges en mois homme)^1/2

Ainsi, pour un projet estimé à 240 JH, soit 12 mois homme, il vous faudra 3,5 Equivalent Temps Plein.

La marge de risque

Sachez qu’en moyenne, 75% des projets informatique dépassent leur délais de 30% ! Une marge de 30 à 35% semble donc correcte, mais ce n’est pas aussi simple que ça. La loi de Parkinson dit “les programmes sont comme les gaz parfaits : Ils prennent toute la place qu’on leur donne “. En d’autres termes « le travail s’étale de façon à occuper le temps disponible pour son achèvement ». Il faut donc évaluer juste, san marge de rique, et garder la marge de manœuvre pour vous et votre budget.

Baisser les coûts ? Rien de plus simple, il suffit d'arrêter la production, fermer la boutique et ne pas oublier d'éteindre la lumière en partant. Pourtant, c'est rarement la solution adoptée par les DSI, dont le budget demeure souvent la seule variable d'ajustement pour faire baisser les frais généraux ou frais de structure, composés à 80% de charges salariales. Non, il faut continuer à faire plus, ou plus vite, mais moins cher. Et le train du numérique n'attendra pas : il faut pouvoir dégager des marges des manœuvres, autrement dit des économies, pour investir dans les technologies de demain.

Voici donc les méthodes les plus connues et les plus efficaces pour maîtriser et baisser vos coûts de fonctionnement.

1 - Rationaliser et optimiser ses achats

C'est la méthode numéro 1 au box-office des économies : mettre la pression sur ses fournisseurs pour qu'ils baissent leur prix. Il est certainement plus facile de demander aux autres de faire des efforts que d'en faire soi-même...mais la méthode a du bon, car elle évite ainsi de jeter l'argent par les fenêtres et de se faire plumer comme le dindon de la farce.

1. Mettre en place une politique d’achat pour réduire le nombre de ses fournisseurs, afin de faire jouer l’effet volume et négocier les prix à la baisse, et simplifier la gestion de ses multiples contrats. Cela passe inévitablement par un référencement (avec généralement un top 10 des fournisseurs que l'on consultera toujours, et un second cercle moins sollicité) avec des prix négociés voire des marges arrière comme dans la grande distribution. Plus le fournisseur fait du chiffre avec vous, plus la remise qu'il vous doit augmente. Avec un tel système, votre fournisseur préféré vous devrait presque de l'argent...
   
   

2. Passer par des appels d'offres, même pour les petits achats, s'ils sont récurrents. Évidemment, organiser un appel d'offre a un coût, ne serait-ce qu'en main d'œuvre interne pour établir le cahier des charges, consulter et recevoir les soumissionnaires, faire son choix. Il faut donc que l'économie réalisée par la mise en concurrence soit supérieur au coût de l'appel d'offre lui-même. A vous donc de faire vos comptes. A titre d'exemple, l'état français impose un appel d'offre marché public à partir de 7.000 €. Supposons qu'un jour homme revienne à l'état 500 € tout chargé (c'est assez bas mais c'est un chiffre rond). Le seuil de 7 K€ représente donc 14 jours homme. Soit 7 jours à deux. Sans préjuger de la performance et de la productivité des équipes de l'état, mener à terme un appel d'offre marché public dans ce délai, cela parait juste impossible.
   
   

3. Ne pas hésiter à remettre régulièrement en jeu certains contrats, notamment ceux portant sur des marchés baissiers comme les télécoms, le stockage, les impressions, le cloud...
   
   

4. Revoir son organisation : faut-il ou non centraliser ses achats au sein d’une direction Achat. Il n’y a malheureusement pas de réponse unique et universelle en matière d’organisation. Une direction des achats permet de structurer votre politique d'achat, de mettre en place le référencement, de négocier avec les fournisseurs...mais a aussi un coût de fonctionnement. On peut ainsi constater que les centrales d'achat de la grande distribution ont permis de réduire fortement les prix d'achat (au point d'étrangler parfois le fournisseur mais cela est une autre histoire), mais leur coût de fonctionnement est devenu supérieur à celui d'un achat direct.
   
   

5. Faire intervenir les cabinets spécialisés dans le cost killing sur des dossiers précis : ils sont souvent bien outillés et plus aguerris à la négociation que vous. Alma Consulting ou Lowendal Massai, qui viennent de fusionner sont les plus connus.

2 - Revoir sa politique de sourcing

Faire ou faire faire, telle est la question. Une entreprise est composée d'une multitude de métiers, mais ne maîtrise évidemment pas tout. Faut-il internaliser, sous-traiter, externaliser certaines tâches voire certains métiers ? Il existe bien sûr des critères permettant d'orienter les décisions. L'entreprise dispose-t-elle de la masse critique pour que l'activité soit rentable en interne (imprimer soit même ses brochures vous coûtera bien plus cher que de la sous-traiter à un imprimeur), a-t-elle les compétences pour faire en interne (construire une salle informatique demande des compétences particulières tant en électricité qu'en climatisation, sans parler de la sécurité physique), s'agit-il d'une activité cœur de métier ou périphérique (numériser des chèques est une opération technique et non financière pour une banque), l'activité est-elle à faible valeur ajoutée, banalisée et devenue maintenant une simple commodité ? On peut donc ainsi tirer quelques lignes et grandes tendances :

1. Externaliser les prestations à faibles valeur ajoutées : le support utilisateur de 1er niveau, le pilotage de l'exploitation, la maintenance de vieilles applications en fin de vie, etc. Attention, les Tierces Maintenances Applicatives et autres infogérances ont une forte tendance à voir leurs coûts exploser après quelques années à cause des multiples modifications apportées aux applications ou à l’infrastructure (changements inévitables mais qui ne sont forcément pas prévus au contrat) et la réversibilité peut s’avérer compliquée (ce qui mettra votre fournisseur en position de force).
   
   

2. Externaliser les services banalisés - mais pas forcément à faibles valeurs ajoutées - tels que la messagerie et le collaboratif. Ceci est notamment encore plus facile désormais grâce au cloud computing et aux offres de Microsoft (Office 365), IBM (SmartCloud Notes) et Google (Google Apps for Work).
   
   

3. Remettre en cause des états de fait : certains services sont traditionnellement externalisés, mais « On a toujours fait comme cela » reste toujours une mauvaise raison.

   Le SIRH est traditionnellement externalisé, notamment pour les fonctions paie et gestion administrative. Éditer, mettre sous pli et affranchir des bulletins de salaire est en effet une prestation de masse. Et même si chaque entreprise a ses propres spécificités en matière de gestion administrative (la gestion du temps et des RTT par exemple), l'offre du marché, très abondante, sait s'adapter; Cabinets d'expert-comptable, solution en mode SaaS (typiquement meilleuregestion.com ou 123paie.fr, mais il y en a plein d'autres), spécialistes de la paie (ADP-GSI, Cegedim, CCMX, etc.).
   L'hébergement de son site Web, pour une petite structure, est lui aussi souvent externalisé. Car le ticket d'entrée pour un hébergement sécurisé, tant au niveau infrastructure que cybersécurité, est élevé.
   Le CRM (Customer Relationship Management) lui aussi curieusement, ne pose plus de questions. Les bons résultats de Salesforce.com en sont la preuve. Évidemment, la gestion de la relation client n'est pas une activité cœur de métier, et l'externalisation, en permettant de baisser les coûts, rend aussi bien des services : elle permet de mieux gérer les variations de volume de clientèle, d'ouvrir le service également le week-end, etc. Mais à l'heure du cross-canal, des réseaux sociaux et du Big Data, il devient nécessaire de pouvoir répondre instantanément au client, que ce soit par téléphone, l'agence, le courrier, le mail ou le « chat », le Web ou encore Facebook ou twitter, d'analyser son parcours, de personnaliser son expérience, de pouvoir lui proposer une aide, ou le relancer s'il s'arrête en chemin. Autant de raisons qui font qu'il est sans doute beaucoup moins intéressant d'externaliser son CRM de nos jours. D'autant plus que la relation client devient un nouvel élément différenciateur, et que sa valeur ajoutée redevient évidente.

3 - Faire des choix technologiques

Je n'ai pas dit "faire les bons choix", même si cela semble évident. Miser sur un mauvais cheval a toujours coûté cher. Mais les "bons choix" de l'un ne sont évidemment pas les "bons choix" de l'autre. Trop simple, pas adapté à la taille de l'entreprise, à sa culture, aux compétences disponibles, trop cher...Comme le dit la sagesse populaire : « le chemin le plus court, c'est celui qu'on connait » ; pour la technologie, c'est un peu pareil. Et pour faire des gains, c'est encore plus vrai. Voici  quelques cas d'école soumis à votre sagacité.

• Introduire l’open source, pour gagner sur les coûts de licence (e.g l'OS Linux, les serveurs proxies Squid, le DNS BIND, le serveur Web TomCat et le serveur d'application Apache, le logiciel de supervision Nagios, la suite bureautique LibreOffice, les services cloud d'OpenStack, l'ETL Talend, le Big Data d'Hadoop, etc.). Les mauvaises langues diront que ce que vous ne dépensez pas en licence, vous le dépenserez en service. C'est vrai si vous ne disposez pas des compétences internes adéquates, certains logiciels Open Source étant plus complexes à intégrer que leur équivalent payant. Mais la majorité des coûts proviennent généralement du support, souvent inutile si ce n'est qu'il rassure les équipes, et là c'est plutôt une question de gestion du changement.

• Étudier l'introduction du CYOD (Choose Your Own Device) voire du BYOD (Bring Your Own Device). Cela donne de bons résultats, notamment pour tout ce qui est smartphone. L'utilisateur est satisfait car il a choisi son propre équipement, au lieu de se faire imposer celui de l'entreprise, et vous faites des économies. Les seuls freins à une adoption massive, la complexité du droit du travail français, qui impose à l'employeur de fournir un travail et les moyens de le réaliser, et les surcoûts que peuvent engendrer le support d'une grande diversité de matériel (et là, tout dépend du degré d'autonomie de vos utilisateurs).

• Prolonger la vie du matériel (retarder le renouvellement des PC, Portables, etc.)

• Opter pour la virtualisation des postes de travail (VDI) et des terminaux légers en remplacement de vos traditionnels PC. Maintenir des PC, leurs logiciels et le dispositif de secours associé (Plan de Reprise d'Activité) coûte horriblement cher. En passant aux terminaux légers (vous payeriez deux postes sinon) et à la virtualisation des postes, vous faites non seulement des économies mais vous vous économisez des ennuis lors des exercices de PRA.

• Rationaliser le matériel et le logiciel (middleware) : l'effet volume de vos achats (cf. paragraphe 1) vous permet de faire baisser les prix et la rationalisation simplifiera la gestion des compétences de vos équipes, ce qui à terme  vous fera également gagner de l'argent. Mais pour rationaliser, il faut avant tout faire un choix. CQFD...

Les choix technologiques restent nombreux et variés, SaaS ou logiciels on-premises, progiciels ou développements spécifiques, Open Source ou licences, Lean IT ou CMMI, autant de questions qui finalement font la beauté du métier de DSI.

4 - Respecter les délais

Coûts, Qualité et Délais sont les trois mamelles des projets informatiques. Mais plus vous rallongez les délais, plus cela vous coûte. Le respect des délais est donc essentiel pour la maîtrise des coûts. Mais gare aux livraisons pleines de non-conformités. Car compresser les délais - ce qui est un peu différent de respecter les délais, vous me l'accorderez - revient souvent pour beaucoup à rogner sur la qualité. Alors qu'il s'agit plutôt d'arbitrer ou simplifier certaines fonctions à développer.

Évitez également les effets tunnels dans les projets : un projet informatique, ce n'est pas la même chose qu'un projet de construction d'une centrale nucléaire ou d'un paquebot. Livrer des fonctions deux ans après que le métier a formulé sa demande, c'est souvent livrer des fonctions obsolètes, et gagner quelques années de maintenance évolutive. Il faut pouvoir lotir et livrer rapidement. C'est d'ailleurs tout l'objet des méthodes agiles, de DevOps et architectures en micro-services. Livrer rapidement mais avec une qualité optimale.

5 - Optimiser son fonctionnement (processus internes)

Comme je viens d'y faire allusion supra, l'agilité, qui consiste à optimiser en priorité les délais et les coûts, est un levier important pour la maîtrise des budgets. Agilité non seulement dans les développements mais aussi dans la gestion de ses infrastructures :

• Les méthodes Scrum et par extension DevOps, même si elles ne sont pas adaptées à tous les types de projet, ont montré leur efficacité.

• La virtualisation des infrastructures, du datacenter, voire le passage au cloud, privé, public ou hybride, permet de gagner en agilité de manière drastique.

• DevOps n'est pas antinomique d'industrialisation, bien au contraire. Il faut savoir utiliser à bon escient les référentiels existants comme ITIL, qui recense les bonnes pratiques en matière de production informatique. Je ne parle pas de CMMI : Tel qu'appliqué, CMMI impose un grand nombre de restrictions inutiles, des processus lourds, des réunions, le tout couplé à une documentation que personne ne lit ou ne maintient, voire ne comprend.

Les méthodes agiles et les outils du Cloud ne sont évidemment pas les seuls leviers d'optimisation. Il est aussi possible de jouer sur son organisation. Comme :

• Supprimer des échelons hiérarchiques intermédiaires et aplatir l’organisation est aussi une façon de regagner en agilité. Évidemment, c'est un remède assez radical que l'on n'emploie que rarement dans les entreprises traditionnelles, mais les "entreprises libérées" (terme inventée par Isaac Getz) ont elles franchi le pas.

• Centraliser (si pertinent) et mutualiser les moyens : si vous disposez de plusieurs services de helpdesk, n’en faites plus qu’un, il sera sans doute plus efficace de par la mutualisation des moyens.

• Créer des centres de services partagés.  C'est au départ une bonne idée : quand l’activité générée sur une technologie particulière ne permet pas de maintenir la compétence au bon niveau, on mutualise la ressource entre plusieurs services, ce qui permet d'optimiser son emploi du temps. On crée ainsi un Centre de Services Partagé. Le problème, c'est que ce CSP voit rapidement ses coûts de fonctionnement exploser : il refacture ses services en interne et n’optimise pas ses propres coûts de fonctionnement, par manque de pression du “client” final.

• Faire la chasse à la sur-qualité et revoir ses SLA (Service Level Agreement). Un client qui demande pour son application une disponibilité de 99% ne peut pas disposer des meilleurs experts.

• Auditer les processus si besoin, afin de les simplifier. Si vos processus impliquent trop d'acteurs d'origine différente, vous avez un problème d'organisation. S'ils requièrent des validations la plupart du temps inutiles (c'est facile à vérifier, si le valideur signe sans savoir, c'est que c'est inutile), vous devez simplifier.

• S'inspirer des pratiques du low-cost : reporter une partie de vos activités vers le client final ou vos partenaires ; Ainsi, la DSI peut faire assurer le support utilisateur par les utilisateurs eux-mêmes, à l’instar de ce que fait B&You, grâce à la  mise en place de forums et de FAQ, voire de réseaux sociaux d'entreprise.

6 - Instaurer une gouvernance de tous les projets

De trop nombreux projets sont encore lancés sans étude de ROI (Retour sur Investissement en bon français), ou avec un ROI bidon (gain de "n" ETP par exemple). Or, pour une DSI,  les investissements d'aujourd'hui sont bien souvent des charges pour demain. Pour mieux gérer ses priorités, il faut donc :

1. Exiger une étude de ROI pour tous les projets avant lancement.

2. Instaurer une Gestion du Portefeuille Projet (GPP), avec ou sans outil, et analyser la valeur de chaque projet (coût, difficultés à faire, apports pour le métier) pour mieux gérer les priorités.

3. Savoir stopper les projets qui sont des échecs ou en passent de le devenir. S'entêter sur un projet, c'est un peu comme le spéculateur qui espère que son action va remonter et qu'il va effacer ses pertes. Non, la bonne méthode est de couper court aux pertes.

4. Sensibiliser et responsabiliser les directions métiers aux coûts informatiques par une “refacturation” interne. Attention toutefois aux effets de bord : comme tout fournisseur, la DSI devra justifier ses coûts.

Les projets stratégiques échappent souvent à la règle du ROI ; ils sont stratégiques, donc on ne peut remettre en cause leur existence. Et pourtant, c'est une erreur. Même un projet dit stratégique doit pouvoir prouver sa valeur, et encore plus facilement qu'un projet lambda. Il ne doit pas être une exception.

7 - Gérer ses actifs

Quand vos actifs informatiques commencent à représenter une somme certaine, il devient indispensable de s'outiller pour les gérer. D'autant plus que les actifs immatériels comme les licences logicielles sont des plus complexes à gérer. Chaque éditeur a ses propres règles de calcul (nombre d'utilisateurs nommés ou simultanés, nombre de processeurs ou de core, nombre de sites déployés, chiffre d'affaire de la société, etc.). Cette complexité est doublée d'un problème d'organisation. Le gestionnaire de la licence (la DSI) n'est généralement pas l'utilisateur ni l'administrateur de la solution. Ce dernier peut ainsi créer des utilisateurs dans le logiciel et mettre ainsi la société hors la loi sans le savoir. Et les éditeurs n'ont plus de complexes : ils auditent régulièrement leurs clients et n'hésitent plus à leur présenter la facture. C'est même devenu un business model pour certains. Il faut donc mettre en œuvre une gestion des actifs avec :

• Un inventaire des licences utilisées ou pas : ce qui permet de contrôler le nombre d'utilisateurs et de désinstaller automatiquement les logiciels non utilisés

• Un inventaire des applications utilisées ou pas : il est alors possible d'arrêter les applications et les serveurs inutilisés.

• Une gestion du cycle de vie des environnements virtuels (ceux de développement et de test notamment) : provisionner de manière agile c'est bien, mais il faut aussi savoir décommissioner, et tout aussi rapidement.

La gestion des licences (Software Asset Management) a souvent été réservée aux grands comptes, mais il faut savoir que certains fournisseurs proposent maintenant ce service par abonnement avec un degré d'automatisation poussé.

8 - Piloter le budget avec une vue globale

Il n'existe pas de maîtrise des coûts sans un bon pilotage du budget. La comptabilité et le contrôle de gestion sont vos alliés : ils disposent d’outils d’aide à la décision, qui vous permettront d'allouer les bons moyens aux bons projets.

Si votre Direction Financière a par ailleurs mis en place une comptabilité analytique de type ABC, vous vous sera plus facile d'identifier vos principaux centres de coûts et les gains potentiels. Vous pouvez également mesurer vos écarts avec le marché ou des DSI équivalentes en faisant faire un benchmark.

9 - Gérer vos ressources humaines et leurs compétences

Le budget RH représente 40 à 60% des coûts de la DSI ; Il faut donc gérer vos ressources et leurs compétences en premier lieu. Or, le plan de formation de la DSI est souvent mal géré. Il se résume, quand il existe, à une liste sans cohérence de demandes variant selon les projets en cours. Or, il est important de prévoir sur le moyen terme, afin de préparer ses équipes aux nécessités de demain. Il faut pour cela disposer d'une cartographie des compétences de la DSI d'aujourd'hui et la cible de demain. Il faut ensuite savoir faire un savant mélange avec les apports extérieurs, qu'ils soient faits par recrutement ou par achat de prestations de services.

Vos ressources projet sont gérés de manière dynamique : vous renforcez vos équipes projets par une montée en charge des équipes (en faisant appel à de la sous-traitance souvent) mais avez-vous pensé à la réallocation de vos propres  ressources internes ? Ces dernières sont trop souvent en silos et ne sont pas gérées de manière assez dynamique. Il faut pouvoir instaurer une plus grande flexibilité des ressources internes.

Dernière arme RH, vous pouvez aussi décider de geler les embauches, ce qui gèlera aussi vos coûts par la même occasion.

10 - Éviter les mauvaises idées

L'enfer est pavé de bonnes intentions. Echanger avec ses pairs permet d'obtenir de bons retours sur certaines idées. Citons quelques exemples d'échecs cuisants en matière de maîtrise des coûts :

• Filtrer l'accès à Internet (en sus des sites illégaux bien sûr): le surf coûte à l’entreprise, il est donc naturel de contrôler son accès me direz-vous. Mais filtrer le web coûte sans doute encore plus cher en gestion et productivité, sans parler de la frustration de vos utilisateurs. Rien que demander l’accès à un site par exemple coûtera du temps à l'utilisateur pour formuler la demande, la faire valider et du temps aux équipes pour la traiter et la tester.

• Couper les budgets à tort et à travers, ce qui met en péril le bon fonctionnement de la DSI, des applications ou leur maintenance ;

• Croire qu’on peut faire des économies sans rien changer. Pour diminuer les coûts, il faut soit arrêter quelque chose, soit modifier quelque chose ; et un changement coûte toujours. Le but du jeu est que le changement coûte moins cher que les économies qu’il rapporte.

L'informatique traditionnelle a toujours été conçue et construite sous forme de silos technologiques : postes de travail, serveurs, réseaux, stockage, logiciels et applications. Pour construire et gérer un système d'information complet, il vous fallait généralement réunir des experts issus de tous ces corps de métier, chose qui était encore assez facile, et les faire travailler ensemble, ce qui était déjà plus dur.

Mais ça, c'était avant, comme dirait mon ami Chris. Car le "cloud computing", le "software-defined datacenter", la convergence des systèmes, les architectures orientées Web, Docker et DevOps sont depuis passés par là et ont rebattus les cartes. Toutes ces technologies, méthodes ou outils peuvent sembler complexes et sans lien particulier entre eux. Mais ils sont en fait souvent complémentaires et peuvent considérablement simplifier la vie des DSI dans la longue transformation de leur traditionnel système d'information vers un système agile, élastique et moins coûteux. Cet article vous aidera à tirer parti de ces nouvelles technologies et nouvelles pratiques.

1 - Le Cloud Computing est l'avenir de l'informatique

Ce titre peut sembler enfoncer des portes ouvertes pour certains. Mais il m'arrive encore de lire des phrases définitives de la part de gens très sérieux comme "le Cloud a été créé par les constructeurs pour relancer les ventes de serveurs dans un marché en berne". Diantre : moi qui pensais que le Cloud permettaient justement aux entreprises d'éviter de brûler leur capital dans l’achat d'infrastructures coûteuses de plus en plus complexes et dans l’embauche d’ingénieurs spécialisés pour les faire fonctionner, de passer de coûts fixes à des coûts plus variables, en rapport direct avec l'activité de l'entreprise. Manifestement, il y a encore en 2015 quelques sceptiques.

Pourtant, dans de nombreux secteurs comme l’automatisation des forces de vente, la gestion de la relation client (CRM), la gestion des ressources humaines, l’approvisionnement en ligne ou les e-achats, les logiciels sous licence existants sont désormais systématiquement remplacés par des solutions SaaS. En fait, le marché s'est retourné en 2012 (3 ans déjà !), suite au lancement en février 2011 par Vivek Kundra, directeur fédéral des systèmes d'information au sein de l'administration Obama, d'une nouvelle stratégie baptisée "cloud first", obligeant les agences fédérales à adopter des solutions de cloud computing par défaut. Ce qui a obligé les grands éditeurs américains à s'adapter, dans le sillage d'Amazon (EC2 a été lancé en 2006 après 4 ans de développement) et de Google. Microsoft, devenu un acteur principal du Cloud avec Office365 et Azure, a même nommé à sa tête Satya Nadella, anciennement responsable de l’offre cloud, c'est tout dire. Le marché européen a suivi dans la foulée. Le Cloud a ainsi généré, selon le Forrester, 58 milliards de $ de chiffre d’affaires en 2013 (dont 62% pour le SaaS), et la tendance devrait se poursuivre avec un CA qui devrait franchir les 191 milliards de $ d’ici à 2020.

Les chiffres communiqués par PAC pour la France en décembre 2014 sont assez parlant : Les entreprises sont ainsi 55% à déclarer recourir à des solutions de cloud, contre 29% en juin 2014. Les entreprises utilisent en priorité des applications en mode SaaS (54%). Les offres IaaS sont utilisées par 46% des répondants à l'enquête du cabinet. D'après ce dernier, elles intéressent plus particulièrement les entreprises de moins de 500 salariés qui utilisent ces solutions pour de l’hébergement d’applications (54%), des tests (49%), et de l’hébergement de sites Web (46%). Le PaaS reste quant à lui en retrait car il s'agit d'une offre essentiellement destinée aux développeurs informatiques.

Les entreprises, en adoptant le cloud, recherchent bien sûr des baisses de coûts, mais avant tout la souplesse, la rapidité de déploiement et la facilité de mise à jour. Car le cloud se caractérise par :

• Des services à la demande : mise à disposition de ressources informatiques ou plus généralement de services au moment où l'entreprise en a besoin.

• Un accès réseau étendu permettant aux utilisateurs d'accéder aux services de n'importe où et depuis divers appareils (le fameux ATAWAD).

• Une mutualisation des ressources : les ressources informatiques sont mise en commun et partagées par plusieurs entreprises, ce qui permet d'optimiser leur taux d'occupation et donc leurs coûts de revient.

• Une élasticité et une réactivité : de nouvelles ressources sont mises à disposition rapidement, voire automatiquement.

• Une utilisation du service mesuré permettant une facturation à l'usage.

Le cloud est l'avenir de l'informatique. Si l'on accepte donc ce fait comme une tendance lourde, il est alors du devoir des entreprises et plus particulièrement des DSI de faire évoluer leurs SI traditionnels pour adopter ces nouvelles technologies et en tirer parti. Encore faut-il bien comprendre comment ce marché évolue, et établir une stratégie adaptée à son entreprise. Faut-il opter pour le cloud public, privé, ou hybride, le mode SaaS, PaaS ou IaaS, être opérateur ou externaliser...les questions sont légions.

2 - Cloud Public, Privé, Hybride ?

Une des premières questions que l'on se pose, lorsque l'on souhaite établir une stratégie Cloud, c'est la question du cloud public ou privé. Pour bien comprendre le problème, posons déjà quelques définitions (je ne reviens quand même pas sur ce qu'est le Cloud) :

• Le Cloud public est géré par un fournisseur tiers et plusieurs entreprises peuvent y accéder via Internet, pourvu qu'elles y soient autorisées. Avec le Cloud public, de multiples entités (tenant) se partagent ainsi les mêmes ressources informatiques mises à disposition par le fournisseur. Le choix de ce dernier devient évidemment critique : fiabilité et pérennité du fournisseur, coût total sur l'ensemble du cycle de vie (transition, exécution et réversibilité du service), flexibilité et agilité du modèle (élasticité technique et opérationnelle, souplesse contractuelle) et portée géographique sont les principaux critères de choix. Pour certains, la nationalité du fournisseur joue aussi, mais ce n'est manifestement pas un critère prépondérant.

• Le Cloud privé est dédié, comme son nom l'indique, à une seule entreprise, déployé en ses locaux, dont l'exploitation est assurée par ses propres équipes ou sous-traitée (on parle alors de Managed Private Cloud, le partage se fait sur les procédures, l’équipe d’exploitation et les outils de suivi) ou hébergé chez un prestataire (on parle alors de Hosted Private Cloud, le partage se fait également sur l'infrastructure du fournisseur). Dans ce dernier cas, il ne sera alors accessible que via des réseaux sécurisés (VPN) aux utilisateurs dûment habilités. Le cloud privé convient bien aux grandes entreprises qui disposent des moyens et des compétences pour construire ou gérer un cloud privé ou à celles dont les besoins en matière de criticité et sécurité des données sont importants. Même si la différence de niveau de sécurité entre un cloud public et un cloud privé hébergé est plus symbolique qu'autre chose.

• Le Cloud hybride est une structure mixte qui permet de combiner les ressources internes du cloud privé à celles externes du cloud public. Une entreprise qui utilise un Cloud hybride peut par exemple avoir recours au Cloud public ponctuellement, pour son Plan de Reprise Informatique (PRI) ou lors de pics d’activité.  Le reste du temps, elle se contentera de ses ressources internes. L’hybride permet en effet d’alterner entre les deux modèles en fonction de la conjoncture et des besoins ; On peut ainsi répartir chaque projet, environnement de développement, maquette ou campagne de tests entre privé et public. Ce mode mixte permet aussi de garder en interne les données confidentielles et de déporter le reste sur un cloud public. Cela diminue largement les charges d'exploitations d'infrastructure, cantonnées au minimum requis. Autre exemple, les couches applicatives d’une application peuvent être hébergées dans le cloud privé et la couche de présentation de cette même application stockée dans le cloud public, puisque celle-ci requiert une grande élasticité et ne gère pas de données critiques. On peut par là même répartir les serveurs frontaux dans le monde entier, au plus près des utilisateurs, et donc réduire le temps de latence.

Comme le montre les chiffres de PAC de décembre 2014 sur le marché français, le cloud public rencontre moins de succès que le cloud privé, mais de peu. Il a surtout de belles perspectives de croissance devant lui. Le cloud privé devrait quant à lui croître modérément. Rien de très surprenant à cela : le cloud privé, surtout interne, reste évidemment plus coûteux que le cloud public, car dédié et non mutualisé. Même s'il est bien adapté aux besoins des grandes entreprises, qui ont des exigences importantes  et/ou spécifiques auxquelles le cloud public a du mal à répondre. Certains oiseaux de mauvais augure prétendent même que le cloud privé est mort. La réponse la plus évidente serait donc d'opter aujourd'hui pour un cloud public. C'est sans doute répondre un peu vite. C'est en effet oublier le poids de l'informatique traditionnelle et les nombreux freins aux changements. On  ne passe pas directement d'une infrastructure traditionnelle interne à un cloud public sans risques majeurs. Le changement est beaucoup trop important, la marche trop haute, pour les collaborateurs (et pas que ceux de la DSI) de l'entreprise. Il faut savoir gérer par pallier la transition pour éviter d'une part toute perte de contrôle et d'autre part un rejet complet des utilisateurs.

Les systèmes d'informations traditionnels ne sont en effet généralement pas conçus pour fonctionner correctement dans le cloud. Les applications ne sont pas toujours compatibles avec la virtualisation, la distribution et la standardisation des composants. De nombreuses applications reposent encore sur des composants logiciels, spécifiques ou standards, dont les versions ne sont plus maintenues ni supportés par les fournisseurs. Autant dire que ces applications ne seront pas éligibles au cloud public immédiatement. Il faut migrer ses composants, adapter ses applications mais surtout apprendre à gérer ses configurations dans le temps. Les composants de votre cloud public seront en effet mis à jour par votre hébergeur et à son rythme. Il vous faudra suivre et adapter vos applications. Pire encore, dans le cadre du mode SaaS, c'est l'hébergeur (en général l'éditeur du progiciel) qui décide de la date de mise en production d’une nouvelle version, et cela pour tous ses clients. Il vous faut alors gérer la formation de vos utilisateurs de pair avec la gestion des changements de votre cloud. Et le rythme des évolutions fonctionnelles peut vite devenir infernal pour vos utilisateurs. Le risque de rejet n'est pas négligeable.

Quant aux grands projets de migration, le recul aidant, les chiffres donnent des indications précieuses : 50% des migrations dépassent leur budget prévisionnel et deux tiers des projets dépassent leur durée prévisionnelle. Il y a manifestement une sous-estimation des difficultés inhérents à de tels projets.

Il n'est donc pas surprenant, dans ce contexte, que le cloud hybride soit le "buzz word" de cette fin d'année. Le cloud hybride constitue en effet une transition moins risquée vers le cloud public. Encore faut-il avoir constitué un cloud privé. Ce dernier n'est pas un concept inventé par les DSI pour contrecarrer les percées du cloud public, comme certains aimeraient le faire croire. Il permet à la DSI de pouvoir exercer pleinement son métier et de se roder à tous les sujets du cloud : catalogue de services, administration, élasticité des ressources, distribution des composants logiciels, facturation, réversibilité, etc. Selon l'adage qui veut que l'on n'externalise que ce que l'on maîtrise, la DSI doit savoir gérer un cloud privé, ce qui implique préparer son infrastructure et ses applications, avant de migrer vers un cloud hybride puis éventuellement vers un cloud 100% public.

Construire, gérer un cloud privé et transformer ses applications ? Vaste programme aurait dit le Général de Gaulle. Passons en revue les composants essentiels à cette transformation.

3 - A l'origine était la virtualisation des serveurs

Quand l'informatique dite distribuée, symbolisée par les mini-ordinateurs VAX de DEC, Unix d'HP et de SUN ou Windows de Microsoft (par opposition à l'informatique centralisée constituée de "mainframe" IBM) est apparue dans les années 90, il était souvent préférable d'installer une application par mini-ordinateur. Il était en effet impossible de garantir, contrairement au mainframe, une isolation et donc une allocation de ressources pour chaque application. Faire cohabiter deux applications sur un même serveur signifiait que l'une pouvait ralentir l'autre. Il fallait de plus s'assurer que la pile logicielle des applications (version d'OS, version des middlewares, etc.) restait compatible dans le temps : si une application requérait une nouvelle version de SGBD (Système de Gestion de Base de Données), il fallait vérifier que cette version n'entraînait pas de régression sur les "colocataires" utilisant ce même SGBD. Dédier un serveur à une application coûtait bien sûr assez cher : cela revenait à multiplier les serveurs, qu'il fallait bien ensuite maintenir et administrer, avec des ressources souvent largement inutilisées : la puissance de calcul du serveur était taillée pour absorber le pic de charge et restait sous-utilisée le reste du temps. Fort heureusement, la mini-informatique a vite adopté les technologies de virtualisation. Elle a autorisé le partitionnement des ressources, permettant sur un même serveur physique d'isoler les applications, et de dédier des ressources à chacune.

Dans un système de virtualisation, les ressources physiques informatiques d'un serveur (principalement les processeurs, la mémoire, le stockage, les accès réseau) sont découpées et affectées à des conteneurs. Ces conteneurs, plus communément appelées machines virtuelles (VM), ne sont rien de plus que des fichiers constituant les ressources virtuelles de la machine. L'hyperviseur (un OS réduit à son simple noyau - kernel) se charge de l'allocation des ressources physiques et de la bonne exécution des VM. Sur cette plate-forme virtuelle, on peut donc installer différents systèmes d'exploitation (Linux et Windows principalement), du middleware et des applications. Les serveurs ainsi virtualisés se composent donc au final du matériel sous-jacent, de l'hyperviseur, du moniteur de machine virtuelle (VMM), des machines virtuelles (VM), des systèmes d'exploitation, des applications et de leur pile logicielle installées sur chacune de ces machines virtuelles.

4 - De la Virtualisation au Cloud Computing

Le Cloud Computing n'est pas une surcouche à la virtualisation, mais en tire grandement partie. L'élasticité (scalability) des infrastructures du Cloud repose en grande partie sur la virtualisation (et la parallélisation des traitements), en apportant une certaine indépendance entre matériel et applications. Mais le Cloud Computing a introduit deux autres composants essentiels sans lesquels le Cloud ne serait pas ce qu'il est et qui sont le catalogue des services qui permet à "l'utilisateur" du Cloud de commander en self-service de nouvelles ressources ou services, et l'automatisation de l'approvisionnement par un orchestrateur, qui permet ainsi de fournir en 2 heures un environnement complet là ou l'informatique traditionnelle met plusieurs semaines, et donc de gagner en agilité et réactivité. On peut rajouter un autre composant, qui est la facturation à l'usage, mais qui est surtout valable pour les opérateurs et qui est moins pertinent pour une DSI mono-client opérant un Cloud privé interne, qui ne peut que répartir ses coûts.

Pour autant, le Cloud Computing dans ses premières versions ne résolvait pas tout : les ressources étaient certes virtualisées pour la plupart, mais encore gérées en silos : réseaux, stockage, serveurs, sécurité...Mais c'était déjà un premier pas vers le Graal : une infrastructure élastique, agile, et sécurisée.

Les différentes offres de Cloud Computing vous sont sans doute assez familières. On représente souvent les formes les plus classiques de Cloud sous une matrice de responsabilité répartissant les rôles entre l'opérateur du cloud et la DSI sur  IaaS, PaaS et SaaS.

L’IaaS et le PaaS ont été pensés comme des services à destination des DSI, et plutôt pour des développeurs alors que le SaaS est directement accessible à tous les utilisateurs habituels du logiciel ou de l'application. Ce qui ne veut pas dire qu'il n'y a aucun travail d'intégration ou de paramétrage, bien au contraire.

En mode SaaS, l'application est souvent (mais pas toujours) gérée par l'éditeur du logiciel, qui au lieu de vendre de la "boîte" et de l'intégration, s'est mis à vendre des "services en ligne", éditeur qui sous-traite en général à un autre fournisseur la fourniture en mode PaaS ou IaaS de l'infrastructure. On retrouve ainsi en cascade les opérateurs de Data Center, fournissant les locaux, les fluides (eau, électricité, groupes électrogènes, batteries), la climatisation et les liens avec les opérateurs télécoms, les opérateurs de IaaS et PaaS, s'appuyant sur les premiers pour fournir une infrastructure informatique, et les opérateurs de SaaS, s'appuyant sur ces derniers pour fournir un service fonctionnel aux entreprises.

Le choix entre ces 3 services dépend de vos besoins et de vos utilisateurs. Vous ciblez vos développeurs, optez pour le PaaS. Vous souhaitez faire héberger vos applications maison sur une infrastructure élastique et réactive, optez pour le IaaS et déployez vos applications dans le cloud. Vous utilisez depuis longtemps des progiciels, passez directement vers le mode SaaS. L'intégration des applications n'est pas un problème, la plupart des éditeurs offrant des interfaces standardisés de type Web Services et supportant les ETL du marché, Talend en tête.

5 - Du Cloud Computing 1.0 au software-defined datacenter

Le Cloud Computing 1.0, basé sur la virtualisation des serveurs et l'automatisation, aurait probablement fait long feu s'il en était resté là. Car l'informatique ne se limite pas à la simple puissance de calcul d'un serveur. Il faut aussi pouvoir allouer du stockage, ouvrir ou fermer des accès réseaux rapidement, augmenter les débits à la demande. Les utilisateurs du Cloud ne se sont donc pas contentés de commander des machines virtuelles. Ils ont aussi commandé le stockage et les débits réseaux qui allaient avec, avec les mêmes attentes en matière d'élasticité et de rapidité. Il fallait donc pouvoir approvisionner de manière dynamique non seulement les machines virtuelles mais aussi la quantité de mémoire, le nombre de processeurs alloués à chaque VM, leur espace de stockage, les réseaux hauts débits associés, l'ouverture des flux à travers les systèmes de sécurité...

Il a donc fallu aussi virtualiser le stockage et l'infrastructure réseau, rendant là encore le service plus indépendant du matériel sous-jacent. Mais pour pouvoir gérer l'hétérogénéité du matériel, la virtualisation ne suffisait évidemment pas : il fallait un logiciel capable d'approvisionner les ressources et de les administrer uniformément, quel que soit finalement leurs différences. L'équivalent d'un hyperviseur pour une machine virtuelle, mais adapté au stockage et au réseau. C'est ainsi que sont nés le Software-Defined Network (réseaux définis par logiciels), le Software-Defined Storage (stockage définis par logiciels) et le Cloud Computing 2.0 (allocation de VM à la mémoire et à la CPU près).

Prenez une baie de stockage : si vous souhaitiez répliquer les données de cette baie de stockage (pour de besoin de PRI ou de haute disponibilité), il vous fallait traditionnellement utiliser les logiciels fournis par le constructeur et "embarqués" dans le matériel du constructeur. Dans le cas du SDS, l'intelligence n'est plus dans l'équipement et liée au matériel mais est remontée dans un logiciel de gestion et d'automatisation. Vous pouvez alors gérer vos baies de stockage hétérogènes comme un seul pool de stockage et allouer des espaces ou répliquer des données depuis ce dernier, et ceci de manière programmable et donc dynamique et automatisée, à travers des interfaces de programmation (API) fournis par les constructeurs. Tant qu'à faire, vous pouvez également gérer la déduplication, le thin provisioning (allocation dynamique des espaces de stockage selon l'usage), les sauvegardes depuis ce même logiciel...

Il en va de même pour les services réseau : traditionnellement, il vous fallait connecter vos routeurs, commutateurs et autres load-balancers, puis les configurer. Avec un software-defined network, vous définissez vos pools de prises réseau (les commutateurs) et vos pools de connectivité (commutateurs cœurs de réseau et routeurs). Vous pourrez alors définir des commutateurs virtuels auxquels seront rattachés des serveurs virtuels, communiquant par des réseaux là encore virtuels.

Le software-defined DataCenter (SDDC) est donc un centre de calcul dans lequel on a étendu les concepts de la virtualisation (l'abstraction, la mise en commun des ressources (pooling) et l'automatisation des traitements) à l'ensemble des ressources et des services du datacenter. Dans un SDDC, tous les éléments de l'infrastructure (routeurs et commutateurs réseaux, équilibreurs de charge, stockage, déduplicateurs, postes de travail, serveurs et composants de sécurité) sont virtualisés et délivrés comme un service, avec un niveau d'abstraction poussé à son maximum. Les services sont pilotés à partir d'un ou plusieurs logiciels de gestion et d'automatisation, permettant à un administrateur de manager tous les composants du centre de calcul, de sa configuration, son approvisionnement à son administration. Cette administration centralisée et cette automatisation sont rendues possibles par la normalisation des API mis à disposition par les composants matériels.

La promesse du SDDC, c'est d'accélérer la mise en œuvre de tous les services informatiques  pour les utilisateurs et les propriétaires d'applications, et de réduire les coûts et de simplifier l'environnement pour les DSI. Encore faut-il, pour tenir cette promesse, que tous les composants du SDDC soient compatibles et interopérables entre eux, me direz-vous. Si votre logiciel de contrôle ne peut pas communiquer avec votre système de stockage faute d'API ouvertes, ou si votre commutateur ne dispose pas d'API permettant de gérer la qualité de service, vous risquez d'avoir du mal à mettre en œuvre et gérer votre datacenter correctement. Le plus simple est donc de préserver une certaine homogénéité dans l'infrastructure, sans pour autant devenir dépendant d'un seul constructeur. Ce qui nous amène naturellement à la question du matériel.

6 - Quel matériel pour le software-defined datacenter ?

Construire son datacenter en silo restait encore relativement simple : Le réseau était jusqu'à présent un élément peu lié au reste de l'infrastructure : il suffisait de prendre des composants interopérables (Cisco, Juniper, Huaweï, etc...) et de choisir son protocole de routage associé à sa topologie. Le stockage demandait un peu plus d'intégration avec les serveurs mais les réseaux SAN et NAS ont permis un découplage important et l'émergence de systèmes de stockage virtualisés (EMC, HDS, HP, IBM, NetApp...). Enfin les serveurs x86, en dehors des mainframes, ont mis tout le monde d'accord sur la base d'OS Linux ou Windows.

Cela demandait quand même de savoir gérer les relations commerciales avec ces différents fournisseurs, qui souvent n’ont pas les mêmes politiques de "licensing", de trouver les compétences nécessaires pour tester l’intégration entre les systèmes et administrer les équipements, et de gérer leur maintenance (gestion des patchs, des versions, des changements). Pas si simple au final...

Mais s'assurer que tous ces matériels sont interopérables et de plus compatibles avec la pile logicielle de votre datacenter demeure une gageure : les matrices de compatibilité des constructeurs ne vous donnent qu'une simple indication et non une garantie sur le niveau de compatibilité de leurs matériels. Seul un test peut vous le dire. Alternativement, on peut reporter cette exigence sur le fournisseur, en optant pour des systèmes déjà intégrés par le constructeur et embarquant nativement une ou plusieurs piles logicielles de gestion.

C'est ainsi que nous avons eu d'abord les systèmes intégrés réunissant dans une même armoire ressources de calcul, stockage et réseau (un bon exemple est Cisco Unified Computing System, qui intégrait le calcul, le réseau et les unités de stockage dans un rack unique de 19 pouces, le tout avec un hyperviseur de type VMware). Puis, par simple innovation incrémentale, les constructeurs ont conçu les systèmes convergés, intégrés et pré-paramétrés en usine (typiquement VCE VBlock, Cisco/NetApp FlexPod, Lenovo PureFlex, Oracle Exadata Database Machine). Les composants d'un système convergé sont intégrés grâce à une pile logicielle unique. C'est le grand "plus" de ce dernier, car sinon, il faut bien l'admettre, cela ressemble encore fortement à un assemblage de technologies existantes classiques dans un seul rack, éventuellement extensible. Ainsi, les vBlock de VCE intègrent les serveurs lames UCS de Cisco, les commutateurs réseaux Ethernet et SAN du même constructeur et des systèmes de stockage EMC. Le tout fonctionnant avec les piles logicielles de VMware (réseaux et serveurs) et d'EMC (stockage). Autant dire que la complexité de ce genre de système reste encore importante puisqu'il faut savoir maîtriser l'ensemble de ces technologies. Mais il permet en même temps de gérer chaque composant séparément. Ainsi, le stockage peut être attaché directement à un serveur mais peut aussi être utilisé comme un système de stockage disjoint, de type SAN ou NAS. L'intérêt des systèmes convergés est de pouvoir augmenter les capacités de son infrastructure en rajoutant simplement un nouveau "bloc" aux blocs existants. On peut ainsi étendre la capacité de son datacenter quasiment à l'infini...

Enfin, les systèmes hyperconvergés (Nutanix, SimpliVity et Scale Computing sont les sociétés les plus en pointe), poussent le concept d'intégration au maximum, supprimant typiquement les besoins d'un réseau SAN dédié au stockage. Les systèmes hyperconvergés consolident sur une seule pile logicielle tous les composants d’infrastructure, comme pour les systèmes convergés, et toutes les technologies intégrées sont administrées d'un point central, sur une console unique, offrant ainsi un service proche de celui d'une "appliance", l'automatisation et la virtualisation en plus. La grosse différence avec les systèmes convergés ? Le logiciel. Par exemple, le contrôleur de stockage n'est plus embarqué dans la baie au niveau matériel mais est assuré par le logiciel, généralement réparti sur plusieurs noeuds d'un cluster, pour assurer la haute disponibilité de la fonction. Typiquement, chez Nutanix, le logiciel centralise la capacité de stockage local de chaque serveur et le configure comme un seul pool de stockage. Les données qui doivent être accédées rapidement seront stockées localement sur disque flash, tandis que les données moins fréquemment utilisées pourront être déplacées sur des disques durs magnétiques classiques ou sur un des serveurs ayant de la capacité en réserve. Un petit film valant mieux qu'un long discours :

Les systèmes hyperconvergés représentent probablement l'avenir des software-defined data center. Ils permettent d'optimiser leur fonctionnement en faisant passer le matériel au rang de commodités. Car ce qui compte dans un système hyperconvergé, c'est le logiciel et notamment le choix de l'hyperviseur global. Même VMware, jusqu'alors partie prenante des systèmes convergés avec VCE, a sorti son propre matériel (une première pour l'éditeur de logiciels) avec "EVO:RAIL" et "EVO:RACK". L'éditeur package ainsi sa suite de logiciels : vSphere (virtualisation des serveurs et gestion du stockage), virtualSAN (virtualisation du stockage), vCenter (gestion des déploiements et administration centralisée, équilibrage des ressources de manière dynamique, etc.), vRealize Log Insight (gestion des logs)...avec du matériel issu d'alliances avec ses partenaires (Dell, HP, et Hitachi pour ne citer qu'eux). Il est bien sûr possible de choisir des systèmes plus agnostiques en matière d'hyperviseurs, comme Nutanix ou d'autres, qui supportent différents hyperviseurs dont KVM, Microsoft Hyper-V, Citrix Xen et VMware vSphere.

Le choix du matériel, convergé ou hyperconvergé, n'est finalement pas si innocent que cela. Il peut vous amener à choisir de facto une suite logicielle ou au contraire vous laisser libre de votre choix. Mais au fait, avons-nous vraiment le choix ?

7 - Quelle "pile logicielle" pour le software-defined datacenter ?

Avec des systèmes convergés ou hyperconvergés agnostiques en matière d'hyperviseur, le choix du matériel importe peu au final. Mais le choix de la pile logicielle gérant ces systèmes est lui crucial. Il existe à ce jour plusieurs grandes alternatives :

Les solutions OpenSource :

1. Apache CloudStack : Ce jeu de composants logiciels est issu du rachat en 2011 de Cloud.com par Citrix, qui cédera un an plus tard les sources à la fondation Apache mais continuera à commercialiser une version payante de CloudStack. CloudStack supporte les hyperviseurs KVM, vSphere et Citrix XenServer mais n'a pas réussi à rallier autant de soutien des constructeurs qu'OpenStack. Il lui manque ainsi de nombreux connecteurs, ou leurs supports sont annoncés en décalage par rapport à son concurrent. Mais contrairement à OpenStack qui peut être vu comme une collection de projets OpenSource et une boite à outil, CloudStack a été conçu d'abord par Cloud.com comme un framework intégré.

2. HP Eucalyptus : un logiciel OpenSource peu connu, racheté en septembre 2014 par HP et sur lequel il a construit une partie de son Cloud Helion privé (cloud bientôt arrêté) et hybride. Il est surtout connu comme compatible avec les API du Cloud d'Amazon AWS. Le projet est né dans le département des sciences informatiques de l'Université de Santa Barbara (Californie). Eucalyptus est ensuite devenu une entreprise commerciale en 2009. En 2012, Eucalyptus Systems a passé un accord avec Amazon Web Services (AWS)  permettant aux DSI de créer des clouds hybrides entre un cloud privé Eucalyptus et un cloud public Amazon Elastic Compute Cloud (EC2).

3. OpenStack (porté par la fondation du même nom) : OpenStack est LA référence OpenSource en matière de cloud privé, car elle a réussi à réunir autour d'elle le support de nombreux constructeurs et acteurs, ce qui garantit une compatibilité maximale avec la plupart des équipements. Elle est très complète mais elle nécessite des développements complémentaires pour offrir une solution clé en main. Il faut aussi pouvoir évoluer au fil des mises à jour OpenStack. Pour ne rien gâcher, il existe de multiples distributions sur le marché, et toutes ne sont pas compatibles entre elles.

   Pour vous donner un ordre d'idée du caractère "boîte à outils" d'OpenStack, cette suite d'outils comprend les modules intégrés suivants :

• Service de calcul (gestion des VM) : Nova ; compatible avec la plupart des hyperviseurs comme HyperV, KVM, VMware vCenter et Citrix XenServer

• Service de stockage d'objets : Swift

• Service d'images (images permettant d'initialiser les VM) : Glance

• Interface Web de paramétrage et gestion (tableaux de bord) : Horizon

• Gestion des identités : Keystone

• Gestion des réseaux à la demande (on-demand networks) : Neutron (auparavant nommé Quantum). Neutron dispose d'un connecteur permettant d'intégrer OpenFlow qui prend en charge la partie "abstraction". Il fonctionne aussi avec OpenDaylight, Open vSwitch, Cisco OpFlex et ACI, Juniper Contrail...

• Service de stockage (service de disques persistants pour les machines virtuelles) : Cinder

• Orchestration (service d'orchestration à base de template) : Heat

• Service de télémétrie (service de métrologie notamment pour la facturation) : Ceilometer

• Service de base de données à la demande : Trove

• Service de Big data grâce à Hadoop : Sahara

• Service de "Bare Metal provisioning" : Ironic

• Service de gestion des systèmes de fichier partagés : Manila

• Service de Middleware à la demande : Zaqar

• Service de gestion des DNS : Designate

• Service de gestion des clés et secrets : Barbican

Notez que l'on peut construire des clouds publics avec OpenStack, comme Numergy (qui s'est mis sous protection judiciaire il y a peu) et CloudWatt, nos deux clouds "souverains", ou encore OVH, Softlayer et Rackspace.

Les solutions propriétaires standard de facto :

1. Amazon Elastic Compute Cloud (EC2) : le modèle d'Amazon est un cloud complètement public, contrairement à celui de VMware. Il s'appuie sur une technologie propre à Amazon (mais basé sur des composants OpenSource) et offre une multitude de services permettant de construire son centre de calcul. Amazon a d'ailleurs renoué avec les bénéfices grâce au cloud. Amazon est maintenant rentable pour le deuxième trimestre consécutif. Le géant américain a dégagé un bénéfice de 79 millions de dollars au troisième trimestre, à comparer à une perte de 437 millions il y a seulement un an. Amazon Web Services compte désormais plus d'un million de clients actifs dans 190 pays et ses ventes ne cessent de progresser. Après avoir grimpé de 81% au deuxième trimestre, elles ont encore bondi de 78% au dernier trimestre, à 2,1 milliards de dollars. Au troisième trimestre, le cloud est même devenu la première source de profits d’Amazon, rapportant 472 millions de dollars, soit 52% du résultat opérationnel de l’entreprise.
   

2. Google Cloud Plateform : Le plus gros concurrent d'Amazon sur le secteur du cloud public, même si Google dispose de moins de services qu'AWS et est plus orienté IaaS et PaaS. Google est aussi probablement meilleur sur le BigData que son concurrent, ce qui ne vous surprendra pas. De la même manière, Google utilise de nombreux composants OpenSource pour bâtir son cloud public.
   

3. Microsoft Azure Pack : il s'agit d'une offre packagée par Microsoft qui permet de construire rapidement un cloud privé, compatible avec le cloud public Azure du même éditeur. Ce qui permet de passer au cloud hybride voir au cloud public (Microsoft) presque sans s'en rendre compte...
   

4. VMware vCloud suite : VMware dispose de tous les modules pour gérer un SDDC : vCenter, vSphere pour virtualiser les serveurs, vRealized (Automation, Operations et Business pour la facturation),  virtualSAN pour la gestion du stockage, etc. C'est sans conteste le leader dans la gestion des clouds privés. Et cela a donc forcément un prix...VMware a l'avantage d'être le pionnier de la virtualisation et dispose d'une importante base installée en terme d'hyperviseur. Ce qui facilite bien évidemment le déploiement du reste de la suite. Certaines entreprises, comme voyages-sncf.com, font néanmoins le saut vers OpenStack pour challenger VMware dans sa politique de tarification.

Nous avons donc le matériel, des systèmes convergés ou hyperconvergés et la pile logicielle (open source ou propriétaire) pilotant ce matériel. Ce qui nous permet de construire et gérer notre centre de calcul (software-defined data center) comme un cloud privé. Mais il faut pouvoir adapter ses applications à ce mode. Et il y a probablement autant de cas particulier que d'applications, même si nous avons déjà pu identifier quelques écueils majeurs, comme la compatibilité des composants. Il est donc difficile de traiter ce sujet en quelques lignes ou même en quelques paragraphes. Il existe cependant des solutions, des architectures et des pratiques bien adaptées au cloud : les Architectures Orientée Web (WOA) basées sur des interfaces de type REST, les architectures micro-services, Docker et DevOps.

8 - Un Cloud privé pour Docker et DevOps

J'ai expliqué pourquoi le cloud privé était une étape à privilégier dans la transition de son SI vers le cloud. Il y aussi une autre raison de vouloir construire un cloud privé. Il ne faut pas oublier les besoins des développeurs de la DSI, eux-mêmes en prise avec les besoins des directions métiers. Ces derniers demandent à la fois des livraisons plus fréquentes de nouvelles fonctions et une plus grande fiabilité dans les déploiements. Mais à quoi bon pouvoir livrer plus rapidement si l'infrastructure ne suit pas ; imaginez (sans trop d'efforts) un projet retardé par la livraison d'un nouvel environnement qui prendrait 6 semaines...Il faut donc être à la fois en mesure de faire evoluer son infrastructure et ses applications rapidement. Tout va finalement de pair, applications et infrastructure.

Et la philosophie de DevOps, qui vise justement à accélérer le rythme des livraisons et à améliorer la qualité des déploiements en production, colle bien à ce besoin. Quand on parle de DevOps, on parle bien sûr de méthodes agiles, d'intégration continue, de tests d'acceptation automatisés et de déploiements continus en production. Mais on parle aussi beaucoup de Docker, cette technologie qui permet d'embarquer tout l'environnement dont a besoin l'application pour s'exécuter, dans des conteneurs. Ce qui facilite grandement le déploiement continu, vous en conviendrez, puisque le développeur n'a plus à se soucier des compatibilités des composants déployés en production, mais dispose des mêmes environnements du développement à la production. Finis les célèbres excuses du développeur du type "c'est bizarre, çà marche pourtant chez moi...". Docker favorise aussi l'indépendance vis à vis de l'opérateur du Cloud, ce qui n'est pas à négliger quand on souhaite passer du cloud privé au public, gérer à son rythme les changements des composants ou faire jouer la réversibilité. Votre application a juste besoin d'un OS hôte et de son conteneur, qu'on peut déployer sur un serveur ou un autre...

Quel rapport entre Docker, OpenStack et le Cloud privé me demanderez-vous ? Et bien parce que les développeurs peuvent s'appuyer sur OpenStack (ou tout autre plate-forme Cloud compatible) pour demander un "hôte Docker", puis utiliser Docker dans leur "hôte Docker" pour exécuter leurs containers. Vous remarquerez au passage qu'il n'est plus nécessaire d'utiliser une technologie de virtualisation, l'hyperviseur étant remplacé par le "Docker Engine", ce qui n'arrange évidemment pas certains fournisseurs. A l'exception de Microsoft qui a besoin de créer une machine virtuelle Linux sous Hyper-V afin de pouvoir lancer Docker derrière.

Bien sûr, utiliser OpenStack, Nova et son plugin Docker pour créer simplement des "hôtes Docker", c'est un peu le marteau-pilon pour écraser la mouche. On pourrait simplement s'appuyer sur les services fournis par Google Container Engine ou  Amazon EC2 Container Service. Mais ce sont là deux services de Cloud public, et non privé. Si votre objectif reste la construction d'un Cloud privé, OpenStack prend tout son sens.

Attention, Docker n'est pas forcément adaptée à toutes les applications (et vice-versa). Ni à tous les niveaux de service. Docker est bien adapté aux applications basées sur des micro-services. Chaque micro-service constitue un composant discret de l'application. Les conteneurs Docker sont un bon moyen d'exécuter le code des micro-services sans attendre le lancement d'un système d'exploitation complet, ni subir la gestion qu'induit une machine virtuelle pour chaque copie. Pour s'adapter aux variations de charge, il suffit de dupliquer "à la volée" les conteneurs et les micro-services qui s'y exécutent : le nombre de copies en exécution augmentera donc avec la charge et diminuera en période creuse. Une application basée sur les micro-services sera également plus facile à maintenir si vous avez adopté DevOps. Les changements seront limités à certains micro-services, sans impact sur les autres services de l'application. On peut donc procéder à des centaines de livraisons par semaine, comme le font déjà les GAFA (Google Amazon, Facebook, Apple).

Par contraste, les applications conçues antérieurement à Docker fonctionnent sur un petit nombre de VM, voire une seule. Tout composant de l'application (front-end,  serveur d'application, back-end) s'exécute au sein de cette ou ces VM. La machine virtuelle est donc toujours taillée en fonction du pic de charge et seul l'hyperviseur pourra récupérer des ressources lorsque l'application est en attente.

Notez que la haute disponibilité n'est pas encore assurée par Docker. Il faut donc utiliser des solutions externes comme les clusters systèmes, solutions traditionnelles mais éprouvées, ou plus innovantes telles que Google Kubernetes ou Mesosphere. Ces solutions permettront aux équipes informatiques des grandes organisations d’utiliser Docker pour les applications les plus exigeantes en termes de disponibilité.

Autre solution innovante : Nanocloud. Cette start-up française peut transformer une application classique en solution web, que l’éditeur pourra administrer comme une solution SaaS native. NanoCloud vise les éditeurs de logiciels principalement, mais aussi les grandes entreprises, propriétaires de patrimoines applicatifs importants. Nanocloud dispose aussi d'une offre "Community", solution fonctionnant sur le modèle open-source, et offrant  aux développeurs une boîte à outils DevOps.

J'ai donc finalement mis en évidence dans cet article quatre axes majeurs dans la transformation des systèmes d'information, permettant de gérer la transition d'un système traditionnel vers un système dans le cloud :

1. Le premier est de construire un cloud privé. Il n'a pas besoin d'être complet ni d'embarquer tout le SI, bien au contraire. Cette étape a deux intérêts majeurs : elle permet de se préparer à migrer vers un cloud hybride ou public, et l'entreprise peut bénéficier de tous les avantages du Cloud et notamment son élasticité et son automatisation.

2. Le second est d'utiliser les services de son cloud pour mettre en oeuvre Docker. Cet outil vous permettra de vous affranchir des dépendances logicielles qui gênent la migration de vos applications. Docker supportera par ailleurs vos applications bâties sur des micro-services.

3. Le troisième est de développer ou migrer en parallèle ses applications en utilisant des micro-services basés sur une architecture WOA et sur Docker.

4. Enfin, profiter du déploiement de Docker pour faciliter l'éclosion des pratiques DevOps au sein de sa DSI, et ainsi accélérer les mises en production des nouvelles fonctions et fiabiliser les déploiements.

Le Cloud Computing, Docker, DevOps et les micros-services, probablement le quarté gagnant des prochaines années en matière de SI...

L'information publiée par le journal "Les Echos" le 29 septembre et confirmée depuis par des sources syndicales a fait le buzz : la Société Générale envisagerait de fermer 400 de ses 2 221 agences que compte la banque en France, et ce d'ici à 2020, soit quasiment 20% de son réseau en 5 ans. Un régime draconien qui se traduira probablement par quelques milliers de suppressions de postes. Du coup, la nouvelle était sur toutes les lèvres, et jusque dans l'intervention de Benoit Legrand, Président de ING France, au Salon Banque et Innovation qui s'est tenu le 1er octobre dans les salons de l'hôtel des Arts et Métiers. Il peut sourire, ING Direct est une banque en ligne et n'a aucune agence. Quant à ING Commercial Banking, la banque de financement et d'investissement dédiée aux grandes entreprises et institutions françaises, elle n'a pas ce genre de problème.

La réduction du nombre d'agences, un mouvement inexorable

La Société Générale n'est pas la seule à réduire la voilure de son réseau de distribution, ni la première. Le Crédit agricole a fermé 50 de ses 325 agences en Ile-de-France, BNP Paribas a fait de même avec 14 agences fermées sur 200 à Paris en 2014. Et le Crédit lyonnais prévoit de supprimer 1 000 postes d’ici 2018, avec à la clef des fermetures d’agences. Le mouvement ne se limite pas d'ailleurs pas qu'à la France. La Deutsch Bank envisagerait de supprimer un quart de ses effectifs. Quant à HSBC, elle annonçait début juin une réduction de ses effectifs de 10%, soit entre 22 000 et 25 000 suppression d'emplois.

En 2009, Le Figaro évoquait déjà la fermeture de 1 000 agences bancaires en France ; On ne parlait pas encore de transformation digitale, même si la banque en ligne et les guichets automatiques étaient déjà bien présents dans les esprits, mais plutôt de surdensité du réseau ; En 2009, la France comptait 1 agence pour 1 607 habitants alors que la moyenne des 27 pays européens était de 2 123 habitants. Nous étions très loin derrière les Pays-Bas, la Grande-Bretagne, ou encore la Suède, qui comptaient respectivement une agence pour 4 544, 4 892 et 4 956 habitants (soit une densité trois fois inférieure). Et ce n'est pas une exception culturelle spécifique à ces pays : les banques néerlandaises ont par exemple réduit le nombre de leurs agences bancaires de 50% en 10 ans et réduit leurs effectifs de 9% (source ING).

Mais les banques françaises avancent plus doucement sur le sujet car elles veulent avant tout éviter des plans de départs qui affecteraient leur réputation. Alors que réorganisations et départs à la retraite - nous sommes entrés dans le papy-boom - permettraient de supprimer 10 à 15% des agences sans faire de vague. Les agences des zones rurales, comptant moins de 4 collaborateurs, sont légion et sont les candidates idéales car peu rentables et sans grand impact social, même si pour certaines banques, ces agences représentent aussi leur image de marque.

Pourquoi fermer les agences ?

Les agences ferment car elles sont tout simplement désertées par leurs clients. Ces derniers fréquentent de moins en moins leurs agences bancaires et utilisent de plus en plus les services en ligne. Des services de plus en plus mobiles et de moins en moins "Internet fixe". Ce que confirment les chiffres fournis par les banques et les sociétés de conseil : en 2007, les clients français de la Société Générale étaient 57% à se rendre au moins une fois par mois dans une agence ; En 2015, ils ne sont plus que 42%. Même tendance du côté de LCL, qui a vu la fréquentation de ses agences chuter de 30% en cinq ans. Une tendance confirmée par la 5eme édition de l'étude du cabinet Deloitte sur la relation banque-clients, publiée le 15 septembre, montrant que le nombre de clients ne se rendant jamais en agences était passé de 14% en 2014 à 24% en 2015. En fait, la fréquentation des agences baisse de 5% par an depuis bientôt 10 ans, et cela va plutôt en s'accélérant.

La concurrence de la banque en ligne

La plupart des clients utilisent les services en ligne de leur banque, depuis l'Internet fixe ou mobile. Pourtant, comme pour l'assurance et le e-commerce, le parcours client est encore hybride et est un mixte des différents canaux de distribution : le client passe d'un canal à l'autre en fonction des opérations à réaliser. L'enquête 2014 de Deloitte le résume assez bien : les canaux Internet et mobiles sont utilisés pour les opérations simples (consultation de compte, virement, commandes de chèque), tandis que l'agence reste privilégiée pour les autres types d'interactions (réclamation, rendez-vous avec son conseiller, simulation de crédit, etc.). Mais les usages évoluent à la vitesse grand "V". L'enquête de 2015 montre en effet que même pour des opérations complexes, l'agence perd du terrain même si elle reste prédominante : le nombre de clients se rendant à l'agence pour des démarches telles que la souscription d'un contrat d'assurance-vie ou la passation d'un ordre de Bourse continue à baisser.

Pour s'adapter à ces nouveaux usages, les banques françaises ont développé de nouvelles banques 100% en ligne, voire 100% mobile, dont les coûts de gestion sont théoriquement bien moindres et qui permettent d’attirer une clientèle plus jeune. La BNP Paribas a ainsi créé Hello bank! en 2014, une banque mobile, en complément de sa banque en ligne, la "Net Agence". La Société Générale a acquis en juin dernier l’intégralité de Boursorama Banque (banque 100% en ligne), tandis que LCL a lancé e-LCL, banque 100% en ligne. Le Crédit Mutuel-CIC - entité regroupant les fédérations du Centre Est Europe, du Sud-Est, d’Ile-de-France, de Savoie-Mont Blanc, du Midi Atlantique, de Normandie, de Méditerranée, de Loire-Atlantique Centre-Ouest, du Centre, du Dauphiné-Vivarais et d'Anjou et le CIC, une filiale allemande (Targobank) - mise sur Monabanq, banque en ligne créée en 1999, alors que le Crédit Mutuel Arkea - entité qui réunit les fédérations de Bretagne, du Sud-Ouest et du Massif Central - a mis la main sur Fortuneo Banque, entité créée en 2006 (le monde du mutualisme est parfois compliqué). Le Crédit Agricole a quant à lui lancé BforBank le 1^er octobre 2009, 9 ans après l'entrée d'ING Direct sur le marché français (ING Direct est le n°1 de la banque en ligne en France et 2eme entrant après Monabanq) et Axa, dernier entrant, a lancé Soon, sa banque 100% mobile en 2014.

Les banques 100% en ligne ne doivent pas être assimilées aux services en ligne des banques classiques. Elles ne viennent pas en complément de l'agence : elles n'ont tout simplement pas d'agences. Toutes les activités bancaires se font donc à distance par plusieurs canaux de liaison, Internet fixe ou mobile, téléphone, webcam, e-mail ou courrier papier. Les contrats peuvent être signés en ligne grâce à la signature électronique ou peuvent faire l'objet d'une souscription papier par l'intermédiaire d'un contrat fourni sous forme de fichier PDF qui doit être imprimé puis envoyé par courrier avec les pièces justificatives. Le dépôt des chèques peut être effectué en ligne grâce à des bordereaux numériques. Les chèques papier sont endossés puis retournés par courrier à la banque en ligne. Les retraits d'espèces sont effectués au moyen d'une Carte Bancaire (Carte Bleue, Visa, Mastercard) depuis n'importe quel automate bancaire de retrait (GAB/DAB). Enfin, les conseillers bancaires à distance sont joignables par téléphone, mail, webcam, chat ou courrier postale. Les banques en ligne ayant généralement des horaires d'ouverture plus amples en journée et le week-end en comparaison des agences bancaires, et ont des frais théoriquement inférieurs aux banques classiques.

Quant aux banques 100% mobile, elles n'ont même pas de site Web mais ne sont consultables que depuis un smartphone ou un mobile. Car le trafic se fait depuis ces terminaux. Elles fonctionnent sinon sur le même modèle que la banque en ligne.

Les "pure players" apparus sur le marché en 1994 ont fait faillite, ou ont été racheté (cf. "Banque Directe", filiale de la compagnie bancaire, ZeBank devenue Egg, BipBop). Mais la banque en ligne a aujourd'hui trouvé son marché. D'après un sondage du cabinet de conseil Simon-Kucher réalisé auprès d'un échantillon de 1 000 personnes en 2014, quelques 7% des Français étaient déjà clients d'une banque à ligne et ils étaient 15% au total à envisager de le devenir (19% chez les 25-54 ans). Une étude de 2015 du cabinet "Bain & Company" le confirme : sur les trois dernières années, les banques en ligne ont gagné 6% de clients par an en moyenne. L'arrivée de la 4G sur les mobiles, qui permet une consultation plus facile des services bancaires, a probablement encouragé les Français à faire le saut. La crise financière, la crise de la dette, la crise tout court est aussi passée par là ; les clients recherchent des banques avec des frais bancaires moins élevés. Et des services simplifiés plus lisibles.

Des chiffres qui cachent une certaine prudence des français : Boursorama, la banque en ligne filiale de la Société Générale, se vantait d'une augmentation massive de ses clients. Entre 12 000 et 13000 nouvelles ouvertures de compte par mois constatées en 2014 alors qu'il y a deux ans, la banque atteignait seulement les 2 000. Mais seulement 40% des clients de Boursorama l'utilisaient comme banque principale.

Ce retard à l'allumage provient en grande partie des freins au changement de banque : «Alors qu'en moyenne près de 25% des clients bancaires se disent insatisfaits de leur banque, seuls 3% des clients changent de banque chaque année», a expliqué l'association UFC-Que Choisir dans une récente étude. «C'est trois fois moins que la moyenne européenne, et cinq fois moins que la mobilité française en téléphonie ou en assurance.». Le crédit (personnel ou immobilier), l'assurance-vie et les comptes d'épargne règlementée favorisent la sédentarité du client et de son compte courant bancaire qui sert de pivot aux opérations de prélèvement et de virement». En moyenne les clients particuliers des banques détiennent chacun environ 7 produits bancaires (y compris le compte principal), dont le fonctionnement est souvent attaché au compte bancaire. Autre obstacle pointé par l'UFC-Que Choisir, «la lourdeur du changement des domiciliations (virements, prélèvements) et les risques d'erreurs lors de ce changement, avec les chèques, en particulier".

Tout cela devrait donc laisser le temps aux banques traditionnelles de trouver un nouveau modèle pour leurs agences. En résolvant un paradoxe : si les français désertent les agences, ils sont encore 55% à souhaiter toujours disposer d’un conseiller attitré (selon un sondage BVA réalisé en 2014 pour la fédération bancaire française) et 57% selon Deloitte souhaitent que leur conseiller ait de solides compétences techniques.

Vers des agences moins nombreuses mais plus spécialisées ?

Puisque le client peut effectuer ses opérations courantes lui-même en ligne, les agences doivent désormais offrir d'autres services pour que les clients aient des raisons de s’y rendre. Surtout que la concurrence des banques en ligne s'intensifie, comme on vient de le voir, et que de nouveaux acteurs entrent sur le marché : les fintechs (start-ups utilisant des technologies innovantes liées au secteur financier) proposent à leur tour des services financiers concurrents en se différenciant fortement par leurs modèles opérationnels, technologiques ou économiques disruptifs.

La Société Générale mise désormais sur des agences plus grandes avec des conseillers de plus en plus experts : une agence pourrait se spécialiser dans les opérations immobilières, une autre se consacrer aux produits d’épargne, etc. Un mouvement qu’empruntent également la BNP Paribas ou encore LCL. Quant aux opérations les plus courantes, elles pourraient encore se faire en agences, mais pas au guichet : le CIC, la Société générale et la BNP Paribas installent des centres automatisés avec des effectifs humains réduits au minimum. Les agences s'automatisent en effet de plus en plus, avec des GAB, ces automates qui vous permettent de retirer des billets ou de la monnaie, de verser des espèces, de consulter votre compte ou de commander un chéquier, des scanners de chèques et des coffres de nuit.

L'automatisation ne touche malheureusement pas que les agences, mais aussi les centres d'appel et les conseillers. Ainsi, grâce au machine learning et à l'intelligence artificielle, ce seront des robots, comme IBM Watson qui discuteront avec vous, ou comme Betterment qui vous conseilleront,  dans vos investissements : spécifiez votre tolérance au risque et vos préférences d’investissement, le robot conseiller s'occupe de la gestion des placements et le rééquilibrage du portefeuille.

Ce constat, certes encore un peu avant-gardiste, peut être dérangeant pour les banques. Si ces dernières réfléchissent à spécialiser leurs agences dans des conseils à fortes valeurs ajoutées, comme la gestion patrimoniale, le conseil dédié à l'immobilier, à la banque privée ou au crédit à la consommation, il y a de bonnes chances pour que ces services soient aussi réalisés par des banques mobiles. Et le français n'est pas à un paradoxe près. S'il réclame un conseiller, et plus d'expertise, il ne vient en agence pour du conseil que dans 14 % des cas ! Dans l'immense majorité des cas, il vient traiter d'une réclamation ou pour de la gestion courante.

La réponse qui semblait évidente l'est du coup beaucoup moins : l'agence avec des conseillers experts ne peut être qu'une des réponses aux besoins des clients. Il est en fait probable que les agences bancaires prennent plusieurs formes différentes : agence bureau pour les rendez-vous, agence complètement automatisée, agence show-room, agence généraliste s'appuyant sur des spécialistes en central, etc.

Les banques expérimentent différents modèles d'agence

Pour définir les modèles les plus adaptés aux besoins de demain, les banques se cherchent, expérimentent et communiquent énormément sur ces ballons d'essai. On trouve ainsi quelques exemples significatifs :

Entre octobre 2011 et avril 2012, la BNP Paribas ouvrait six agences « nouvelle génération », avec la possibilité d'avoir des entretiens en côte-à-côte entre les clients qui le souhaitent et leur conseiller, et face à l'écran, grâce à un mobilier spécialement adapté, la possibilité, au cours d'un rendez-vous avec un conseiller de l'agence, de faire appel en visioconférence à un expert BNP Paribas, spécialiste des sujets d'épargne ou de crédit, une zone d'attente active autour d'une « table d'hôtes ou bar à tablettes» équipée de bornes tactiles ou d'iPad présentant l'offre de la banque, un accès à la presse ou encore des jeux pour les enfants, et un espace "Libre-Service" équipé d'automates permettant de réaliser toutes les opérations courantes, sur des plages horaires élargies (retrait, dépôts d'espèces et de chèques, accès aux comptes). Le réseau BNP Paribas devrait ainsi être divisé à terme en trois catégories d’agences : les « agences express », avec automates ou tablettes pour les opérations du quotidien ; les agences « conseil » avec des conseillers généralistes et la possibilité de réaliser une visioconférence avec un expert ; et les agences « projets » avec des conseillers spécialisés.

Début 2014, le Crédit Mutuel Arkéa "réinventait l’expérience client" avec de nouvelles agences "digitales". Là encore, la nouvelle agence fait la part belle aux supports tactiles avec un bar à tablettes, aux grands espaces avec des écrans muraux, au libre-service, et propose même un coin café et une zone pour consulter la presse locale pour plus de convivialité. Avec un positionnement clairement moins commercial et plus dans l'accompagnement. Fin 2014, le Crédit Mutuel Arkéa lançait également le déploiement de la technologie iBeacon dans son réseau d’agences, par l'intermédiaire d'une nouvelle application maison. Le Beacon est une technologie de géolocalisation beaucoup plus précise que le GPS. Elle permet de localiser précisément la position du client dans l'agence et d'envoyer des informations sur son identification par bluetooth. Les clients ayant téléchargé l’application pouvaient donc être « identifiés dès leur entrée dans l’agence » et leur conseiller prévenu de leur arrivée.

Le 7 avril 2015, la Caisse d'Epargne Lorraine Champagne-Ardenne a dévoilé  « une agence 100% innovante » à Metz.  300 m2 répartis sur deux niveaux, un écran interactif sans contact à l’extérieur de l'agence (sans contact car l'écran se trouve derrière la vitrine, pas devant), une borne d’accueil tactile pour signaler son arrivée directement aux conseillers, un « bar à tablettes », un hot-spot wifi, une table tactile (Microsoft Surface) dans le bureau du conseiller (avec de la documentation, mais aussi de l'aide sur les services en ligne, et des jeux pour enfants), la possibilité d'avoir des entretiens en côte-à-côte. A noter un espace de travail partagé pour les conseillers qui n'ont plus de bureau attitré. Cela leur permet de travailler en mode collaboratif, quand ils ne sont pas en rendez-vous clientèle. Tout ceci ressemble furieusement aux agences innovantes de la BNP. D'ailleurs la Caisse d'Epargne a également annoncé, à l'instar du Crédit Mutuel le prochain déploiement de iBeacon.

L'agence bancaire de demain sera multiforme et multicanale

A travers ces expérimentations, on trouve ainsi plusieurs modèles d'agence possibles :

• Les agences sans employés, entièrement automatisées, avec Guichets Automatiques Bancaires, Scanners de chèques, Bornes automatiques, organisées en espaces libre-service.
  

• Les agences moyennes regroupant des conseillers généralistes qui pourront recourir à l’expertise des grandes agences via la visioconférence notamment.
  

• Les grandes agences conçues comme « des pôles d’expertise », regroupant des conseillers généralistes et des conseillers spécialistes. Les conseillers sont alors organisés par produit, comme dans un grand magasin de bricolage où vous trouvez le vendeur spécialiste de l'électricité, de la peinture, etc.

• Les agences bureaux (ou agence à l'étage) qui ne proposeront que des rendez-vous, typiquement pour la clientèle professionnelle.

L'aménagement des agences change aussi. Car l'agence bancaire est une boutique comme les autres. Elle se structure donc en espaces dédiés :

• Des espaces pensés comme un café : un endroit convivial favorisant les échanges avec café, presse, jeux pour enfants, etc.

• Des espaces axé sur le tout numérique (avec probablement un équilibre à trouver entre le numérique et l'humain, car il y a parfois overdose d'écrans) : des bars à tablettes, des bornes interactives, des murs d'écrans interactifs ou pas, extérieurs ou intérieurs, des tables tactiles, des écrans pour les entretiens en côte-à-côte. Tout ce dispositif venant en appui au conseiller.

Enfin, l'organisation des agences changent également :

• Un conseiller n'est plus forcément attaché à une agence donnée, mais peut partager son temps entre plusieurs agences.

• L'agence n'est plus forcément ouverte 5 jours sur 7, du mardi au samedi, mais peut fermer certains jours.

Les banques en ligne viendraient en complément du réseau des agences des banques traditionnelles; Leurs services pourraient être consultés au sein de l'agence, avec l'assistance ou pas d'un conseiller. On retrouverait ainsi le mixte canal numérique / canal physique que les boutiques se plaisent à recréer avec les offres de "click and collect". On pourrait ainsi imaginer commander des devises sur Internet et les retirer en agence, comme le propose déjà ICE. Car pour faire (re)venir le client en agence, il n'y a pas de mystère. Il faut coupler les services numériques, mobiles, et l'agence. Et cela commence déjà par les moyens de paiement. Car rappelons une évidence, c'est au moment de passer à la caisse qu'on a le plus besoin de sa banque.

Relativisons : la nécessaire transformation du réseau de distribution des banques n'est que la partie émergée de l'iceberg : les banques devront affronter d'autres changements majeurs dans les prochaines années. Concurrence des banques en lignes, des "fintech", révolution des moyens de paiement, nouveaux services disruptifs, poids du réglementaire, les sujets ne manquent pas.

 Les impacts de la transformation digitale sur la DSI : Première partie

La transformation numérique, qu'on appelle aussi digitale (anglicisme issu de "digit", chiffre, nombre, qu'il ne faut pas confondre avec digital, du latin digitalis, de digitus, doigt), sans doute parce que parler de numérisation, cela fait penser à une simple dématérialisation de document par scanner, alors qu'il ne s'agit pas que de cela bien sûr, la transformation numérique ou digitale disais-je donc, décrit les profonds changements de notre société provoqués par l'introduction massive de nouvelles technologies numériques dans tous les domaines de notre vie, doublée d'une révolution des usages.

Le client d'aujourd'hui, et principalement celui de la génération Y ou Z, est devenu mobile, utilise son smartphone pour ses achats, ses voyages, ses loisirs ; Il est "social", il communique beaucoup sur les réseaux sociaux ; Il est hyper connecté : il a vécu la consumérisation de l'électronique s'est essayé au BYOD.

Tous ces changements ont induit de nouveaux rapports entre l'informatique et ses utilisateurs, entre l'entreprise et sa DSI. Même si rien n'est encore écrit, analysons ce qui pousse la DSI à changer et à s'adapter pour mieux servir et innover. Mais regardons d'abord la transformation numérique alliant innovations numériques et révolution des usages, avant de détailler celles qui impactent la DSI et les évolutions possibles.

1 - Innovations technologiques...

Je me suis souvent amusé avec mes enfants à jouer au paradoxe de l’œuf et de la poule. Qui de l'œuf ou de la poule est arrivé le premier ? Question qui n'a pas de réponse absolue. Et je peux me poser la même question au sujet de l'innovation et des usages. Est-ce l'innovation technologique qui pousse les usages à changer ou est-ce l'usage et les nouveaux besoins qui poussent les entreprises à innover ?

En fait, tout dépend probablement de la nature de l'innovation et de l'importance du changement qu'elle induit. Néanmoins, nous pouvons être sûr d'une chose, c'est que nous vivons aujourd'hui une période où les innovations se succèdent à un rythme important et qu'elles sont pour beaucoup disruptives (voir mon billet sur les 10 technologies de rupture), c'est à dire qu'elles transforment profondément nos usages et nos sociétés.

L'innovation est couramment définie comme une invention qui a rencontré un marché. L'innovation technologique peut donc se définir comme la création ou l'invention d'un nouveau produit ou service, ou d'un nouveau procédé de fabrication. Rien de neuf, je ne fais que reprendre la définition de l'innovation technologique, communément employée dans la littérature universitaire.

• Ainsi donc, on parlera d’innovation de produits ou de services quand elle consiste à créer ou améliorer un produit ou une prestation de services. La création porte en elle une importance de changement beaucoup plus forte que l'amélioration, ce qui fait que certains ne considèrent pas l'amélioration comme une réelle innovation mais c'est pourtant bien le cas. A titre d'exemples, on peut citer :
  

• Le feu ; bon d'accord, c'était il y a plus de 450 000 ans...mais sans feu, pas de civilisation.

• Le papier ; sans le papier, pas d'écriture et pas de transmission du savoir...Même si ironie du sort, le numérique doit "ubériser" cette invention avec celle de l'imprimerie...

• La vaccination et l'antisepsie ; si elles ne vous ont pas changé la vie, elles vous l'ont sauvée !

• La roue, qui a permis d'autres inventions comme la bicyclette, la voiture...

• Le circuit intégré, qui a rendu possible la miniaturisation, telle que nous la connaissons maintenant, avec le téléphone, la télévision...

• Les logiciels de traitement de texte, Internet, etc. etc.
  
  

• On parlera plutôt d'innovation de procédé (ou de processus) quand elle correspond à la mise en œuvre de nouvelles techniques ou l’amélioration des techniques permettant la production ou la distribution de produits ou la réalisation de prestations de services qui existent déjà (difficile de parler d'innovation de produits dans ces cas là). Donnons quelques exemples pour mieux cerner la différence avec les produits et services :
  

  • La culture hors-sol (oui je sais ce n'est pas bon)

  • La Conception Assistée par Ordinateur (C.A.O) ou mieux encore la Gestion de la Production Assistée par Ordinateur (G.P.A.O).
    

  • Le système de traçabilité des marchandises par code à barres, ou plus récemment par puces RFID

  • La vente en ligne ou encore le "Click & Collect" ( appelé aussi Web to store)

  • La livraison par drone, etc. etc.

L’innovation technologique répond à un besoin du marché (il s'agit dans ce cas plutôt d'une amélioration) ou plus généralement anticipe des besoins futurs (nous sommes alors plutôt dans la création). Ainsi, le téléphone mobile a plutôt créé le marché qu'il n'a répondu à un besoin clairement exprimé. Et a complètement bouleversé le marché de la téléphonie et nos usages. On distinguera donc 4 niveaux d'importance dans les changements. 2 très connus, qui correspondent aux innovations de rupture et incrémentales, et deux, moins connus qui correspondent à des innovations de combinaisons ou de transposition :

1. La rupture : on parle d'innovation disruptive ; L’innovation de rupture introduit un changement majeur qui permet de créer de nouveaux marchés ou de modifier nos comportements de consommation voire la société. Elle vous donne un avantage compétitif majeur par rapport à la concurrence mais en contrepartie, le niveau de risque et d’incertitude est très élevé voire parfois total. Le marché est souvent à créer. Nous connaissons tous des innovations de rupture :

   1. La voiture, qui a révolutionné le transport, le réfrigérateur ou la machine à laver le linge...

   2. Le courrier électronique qui a modifié nos façons de communiquer et transformé les métiers des postiers

   3. La carte bancaire, en remplacement du chèque, du liquide et des devises

      ou encore plus récemment

   4. Uber, qui a révolutionné le marché de la Voiture de Tourisme avec Chauffeur (VTC), pour ne pas citer son service jugé illégal UberPop, BlaBlaCar, qui a modernisé le covoiturage et répondu à un besoin de transport à bas prix, AirBnB, qui taille des croupières aux hôteliers avec une offre radicalement différente de celle des hôtels traditionnels.

2. La combinaison : l'innovation résulte d'une combinaison de produits ou services déjà existants. L'importance du changement induit par ces combinaisons peut varier selon leur nombre mais est généralement importante. Les produits les plus connus :

1. L'iPhone, qui n'est pas une innovation résultante d'une invention particulière mais l'intégration dans un seul et unique appareil d’un écran tactile capacitif multipoint , d'un appareil photo/caméra, d'un système de géolocalisation intégré ainsi que d'un logiciel de cartographie, d'un iPod, et surtout d'un navigateur Internet permettant d’être connecté à tous les services Internet et d’un client de messagerie, sans compter les fonctions élémentaires telles que le téléphone, les SMS et les MMS. L'iPhone représente une innovation utilisant une dizaine de combinaisons.

2. Le Kite Surf, sport très à la mode en ce moment, et qui est la combinaison d'une planche de surf et d'une voile de parapente, deux sports pré-existants par ailleurs.

3. L'amélioration : on parle d'innovation incrémentale ou cumulative, car l'innovation ne crée pas un nouveau produit ou service mais y apporte une amélioration sensible. Le changement est généralement mineur en termes d'impacts. Citons :

   1. Les évolutions successives des réseaux de communication mobiles, 2G, 3G, 4G et bientôt 5G. La 2G a introduit le numérique dans les communications, la 3G a permis des débits plus importants et les transmissions de données (en 2G, le mobile devait être utilisé comme un modem). La 4G apporte des débits 3 fois plus rapide qu’en 3G. La différence avec le Wifi s'estompe.

   2. Les améliorations apportées aux télévisions à écran cathodique, de l'écran LCD et plasma en définition HD puis Full HD, puis à LED en 3D aux écrans 3D UHD et maintenant OLED UHD 3D. On peut aussi citer les iPhones 1, 2, 3, 4, 5, 6...et autres iPad...

   3. La locomotive à vapeur, puis à diesel, puis à électricité, puis à suspension magnétique

4. La transposition : il s'agit d'une innovation résultante de la copie et/ou l'adaptation d'une précédente innovation, d’un secteur vers un autre secteur. C'est une notion un peu floue mais les exemples sont parlants :

1. L'autolib' est la transposition à l'auto de vélib', eux-mêmes inspirés des vélos jaunes de La Rochelle.

2. Les "drive" des hypermarchés, directement inspirés des drives des fastfoods (ils ont d'ailleurs utilisé le même anglicisme).

Cette classification des innovations, cela peu paraître de l'ordre du détail, mais elle a deux grands avantages pour moi. Elle permet d'une part de ne pas passer à côté d'une innovation en donnant des critères objectifs : Microsoft a longtemps raillé l'iPhone, rappelez-vous de l'interview de Steve Balmer en 2007 : "500 dollars?  Fully subsidized? With a plan?  I said that is the most expensive phone in the world.  And it doesn't appeal to business customers because it doesn't have a keyboard.  Which makes it not a very good email machine". Et bien, il n'aurait pas du...Quand j'ai vu et touché l'iphone pour la première fois, j'ai su que cela allait être une tuerie. Cette classification permet d'autre part de mieux cerner un des sujets de mon article, les innovations disruptives et incrémentales.

2 - ...Et révolution des usages

L'innovation d’usage est le changement introduit dans la manière d’utiliser le produit ou de consommer le service. Pour comprendre comment les usages changent, il faut d'abord comprendre les nouveaux utilisateurs. Notamment ceux qu'on englobe dans les appellations "Générations Y et Z".

Inventées par des sociologues outre-Atlantique, ces typologies sont souvent caricaturées par les médias. Elles permettent néanmoins d'analyser les changements que nous vivons aujourd'hui. On distingue la génération X, née entre 1960 et 1970, c’est-à-dire les quinquagénaires; Les "Y" sont nés quant à eux dans les années 1980 et 1990, aujourd’hui quadras. C’est cette même génération que l’on qualifie de «digital native» car née avec Internet. Enfin, on parle de la génération Z, née à partir de 1995 avec le Web 2.0. Communication paroxystique, mobilité incessante, information instantanée sont dans l’ADN des "Y". On insiste sur leur souhait d’avoir un plus grand équilibre entre vie privée et vie professionnelle. Ils sont considérés comme à la fois individualistes et coopératifs au travail. Ils apportent avec eux, au sein de l’entreprise, un usage précoce du numérique acquis à la maison. Par comparaison, la génération suivante, la Z, est hyper-connectée mais plutôt «Web 2.0 » (orientée réseaux sociaux), avec un goût pour le ludique qui se retrouve aussi au travail. Ils seraient encore plus « zappeurs » que leurs aînés, les Y.  Habitués à se débrouiller seuls, les jeunes ont un rapport étroit et inné aux TIC et une culture de l’instantanéité (selon une enquête de l’Observatoire des Usages du Numérique, 48% des personnes répondent dans la minute à un SMS et 30% dans l’heure. En retour, 28% s’attendent à une réponse dans la minute et 38% dans l’heure). Ce besoin d’immédiateté est devenu une constante : ils peuvent ainsi passer d’un site marchand à l’autre si le premier est jugé trop lent. Plus instruits et diplômés que leurs aînés au même âge, ils privilégient l’apprentissage par l’action, le développement personnel et la quête de sens. Rétifs aux contraintes, mais dotés d’un esprit communautaire, ils jonglent avec les réseaux sociaux, les portables et l’informatique de manière intuitive et innée. La Génération Z attache une grande importance aux communautés virtuelles, aux réseaux sociaux, et est friande des avis de ses pairs (ranking des sites Web). Elle accorde d’ailleurs plus d’importance à ces derniers qu’aux propres réponses qu’elle peut obtenir du site de la marque ou de l’entreprise.

Cette analyse sociologique permet d'identifier 4 grandes tendances dans les usages d'aujourd'hui :

2.1 Le partage et le collaboratif : Bien sûr le partage et le collaboratif doivent leur essor aux technologies qui permettent la mise en relation des individus mais il s'agit aussi d'un mouvement de fond plus important que le simple covoiturage illustré par la réussite de BlaBlaCar. Car les sociétés de partage fleurissent : Drivy ou Koolicar  pour l'autopartage, "couchsurfing", entreprise assurant la mise en relation de personnes proposant ou cherchant un service d'hébergement temporaire et gratuit. Il existe d'autres mouvements comme le coworking : destiné initialement aux indépendants, le coworking permet de partager des locaux, des ressources ou services (lignes téléphoniques, accès Internet, assistance informatique, gestion du courrier, etc…) mais aussi et surtout des compétences et des projets. Citons encore le crowdfunding (financement participatif en bon français)  qui permet aux internautes d'apporter l’argent nécessaire à la réalisation du projet en contre-partie d'une rémunération en nature ou en argent. Ou encore la cocréation qui consiste, pour une entreprise, à développer des produits ou services en collaboration active avec ses clients et ce, de façon durable. Le meilleur exemple est celui de Lego, avec son site "ideas", qui incite les fans de la marque à soumettre leurs idées de kit Lego ou à aimer et supporter les idées des autres. Les meilleures idées sont effectivement mises sur le  marché. Cette initiative fait partie de ses nombreuses initiatives dans le numérique, des jeux vidéos au film en passant par Lego ReBrick, communauté pour les fans de la marque.

2.2 L'usage et la fonctionnalité : Nous sommes passés d’une économie de la propriété à une économie de l’usage (ou de la fonctionnalité) : on ne vend plus un produit mais un usage. L’exemple le plus connu est celui de la musique en ligne, de Deezer à Qobuz en passant par spotify. Les ventes de musique sous forme de CD se sont écroulées, compensées pour partie par la musique dématérialisée (iTunes ou Amazon en sont de bons exemples, mais le téléchargement légal de mp3 est toujours basé sur le modèle de la possession), mais surtout remplacées par les services de streaming : on écoute mais on ne possède plus. Et plus encore, on partage en créant des playlists qu’on transfère ou qu’on échange (cf. l'économie de partage supra). Les offres de Vélib' et Autolib' dérivent également de ce mouvement.

2.3 La mobilité et l'instantanéité : Les internautes se font mobinautes et impatients. Cela parait simple à dire mais les impacts sont énormes ; Cela signifie d'une part que l'utilisateur utilise de plus en plus son smartphone et de moins en moins son PC ou sa tablette (ce qui explique d'ailleurs l'attrition de ces deux marchés). Il faut donc développer en conséquence des services. Il faut d'abord que les serveurs soient "ubiquitaires", c'est à dire accessibles n'importe quand, de partout, de n'importe quel terminal. C'est le concept ATAWAD (Any Time, Any Where, Any Device). Car il faut pouvoir répondre tout de suite et à toute heure, et sur n'importe quel canal (ou presque). Il faut ensuite adapter les services aux possibilités qu'offrent les smartphones, notamment la géolocalisation. C'est ainsi que les e-services deviennent les m-services.  On voit donc apparaître des applications de guidage, communautaires de préférence (Waze, iCoyote), de services VTC comme Uber qui géolocalise le client et le conducteur pour les mettre en relation, des applications de paiements, de loisirs (tripadvisor, allociné vous proposent leurs adresses à proximité) ou de santé (Runtastic qui allie GPS, application mobile, objets connectés et réseaux sociaux).

2.4 Les réseaux sociaux et les communautés : Les réseaux sociaux sont des outils qui permettent de publier de l'information, de la partager avec votre communauté d'amis ou de "followers", de discuter et communiquer (chaque outil dispose de sa messagerie classique et instantanée) et de réseauter en vous créant de nouveaux contacts. Si les réseaux sociaux sont si importants pour l'économie, c'est qu'ils pèsent lourds dans la confiance qu'on accordera à un site marchand ou dans l'attachement à une marque ; 14% des consommateurs que nous sommes font confiance à la publicité (la notoriété cela joue), mais 70% font confiance dans les avis que laissent les autres consommateurs et surtout 90% font confiance dans les avis de leurs amis.

Les entreprises l'ont bien compris. C'est pourquoi vous pouvez noter votre chauffeur ou votre passager sur BlaBlaCar, votre hébergeur sur AirBnB, votre restaurant ou hôtel préféré sur TripAdvisor, partager votre parcours santé et vos progrès sur Facebook grâce à Runtastic, etc. Et il n'est pas un site d'information qui ne vous propose de dire "j'aime", de "twitter", ou poster sur LinkedIn, voire les 3 à la fois si vous avez liés vos comptes.

Vous l'avez compris, cette transformation numérique est à l'origine de nombreux changements dans notre vie quotidienne, dans nos habitudes de travail et dans l'organisation des entreprises. Tout ceci donc pour en arriver à cette question cruciale : En quoi la DSI est-elle impactée par ses changements et pourquoi doit-elle s'adapter ?  Ceci nous amène sur la seconde partie de mon article.

 Les impacts de la transformation digitale sur la DSI : Deuxième partie

3 - Les DSI face aux changements technologiques et des usages

Nous avons vu dans la première partie de cette article que le "buzz word" de cette année 2015, la transformation digitale, était une sorte de cocktail explosif entre les innovations technologiques d'une part et les révolutions des usages d'autre part. Ces changements touchent évidemment tous les secteurs et tous les métiers.

Le numérique apporte de nombreux avantages, parmi lesquels nous pouvons citer :

• Une relation directe avec le client : il n’existe pas d’intermédiation entre l’entreprise qui produit et le consommateur.

• Une capacité à innover : les services numériques permettent de créer de nouveaux services, sans apport important de capital et avec une vitesse de déploiement inégalée (cf. Uber).

• Une meilleure communication entre salariés, mais aussi avec les partenaires ou fournisseurs.

• Une meilleure performance financière, liée à une meilleure productivité.

Les entreprises doivent donc s'adapter à toute vitesse, se transformer ou mourir comme on peut le lire. Et quand on parle de transformation de l'entreprise, on parle de tous les métiers. Notamment la DSI. Dans cette seconde partie, je traite donc plus spécifiquement des aspects la transformation digitale et de ses impacts sur les DSI des entreprises.

3.1 La Consumérisation et la Prosumérisation de l'IT : Nous avons vécu un renversement des priorités ; là où l'informatique du 20eme siècle était mise au point dans les laboratoires pour des usages militaires et professionnels, puis évoluait doucement vers le marché domestique, les produits d'aujourd'hui sont créés d'abord pour le grand public avant d'être adaptés au marché professionnel. Ainsi, le blackberry a été créé pour l'entreprise, alors que l'iPhone a été conçu pour le grand (mais aisé) public. Devinez qui a gagné ? Et qui attaque désormais le marché pro avec ses iPhone mais aussi ses iPad Pro ? C'est le phénomène de consumérisation de l'informatique.

Désormais, pas besoin d'être "geek" pour avoir, qui un meilleur PC portable, qui un meilleur smartphone, qui un accès Internet plus rapide, chez soi qu'au bureau. Quoi de plus naturel que certains aient alors voulu utiliser leurs équipements personnels au sein de l'entreprise, en remplacement de terminaux jugés archaïques. C'est le phénomène de "Prosumérisation" de l'IT, qui rattrape les entreprises et les DSI sous la forme du "Bring Your Own Device" (BYOD, apporte ton propre équipement).

Pourtant, en dehors du smartphone, ce mouvement a finalement pris peu d'ampleur en France et en Europe comparés aux États-Unis et à l'Asie. En cause, la rigidité du code du travail et ses casses-têtes juridiques (l'employeur a l'obligation de fournir les moyens de travail et des obligations vis-à-vis de la collecte des données personnelles), des risques de sécurité non maîtrisés, des contraintes budgétaires (déployer une solution BYOD demande des investissements parfois non négligeables), des problèmes d'ergonomie (qui n'a pas pesté contre l'interface de Good Technologie venant remplacer celle d'Apple), ou encore de fausses promesses de baisse des coûts (subventionner et supporter une multitude de terminaux coûte cher). Notons aussi que la DSI a réagi face à la "menace" du BYOD en adaptant son offre de terminaux et en prônant le CYOD (Choose Your Own Device), offrant à l'utilisateur le choix d'un équipement dans une liste approuvée au préalable par la DSI.

Il ne faut pas pour autant négliger ce mouvement, car il impacte largement le smartphone, terminal qui est aujourd'hui privilégié pour lire ses mails et consulter son agenda, mais qui donne aussi de plus en plus accès au SI (interne ou dans le cloud), via des "apps" ou le web, grâce au responsive design et au HTML5. Le smartphone permet aussi de prendre la main à distance sur son PC via un VPN classique et des outils comme Microsoft Remote Desktop (disponible sur Android, iOS et Windows Phone), Chrome Remote Desktop ou TeamViewer. Il devient aussi poste de travail avec Continuum et les applications universelles de Windows 10. Il est donc important de bien encadrer l'usage de ces smartphones, très prisés des générations Y et Z, hyper-connectées, mais aussi des cadres dirigeants. En mettant notamment en oeuvre des solutions d'Enterprise Mobile Management, concept qui regroupe 3 grandes fonctions clés :

1. Le Mobile Device Management (MDM) qui permet de gérer les différents terminaux en poussant des paramètres ou en effaçant les données à distance en cas de perte.
   

2. Le Mobile Application Management (MAM), qui permet de gérer l'ensemble du cycle de vie des "apps", de leur distribution via la boutique d'applications d'entreprise (App store privé) à leur suppression. Il est aussi possible d'isoler les applications professionnelles des autres applications par cet outil.

3. Le Mobile Content Management (MCM), qui offre une consultation et une gestion sécurisées des documents de l'entreprise stockés sur des serveurs de fichiers, dans Sharepoint ou dans l'intranet de manière générale.

L'Enterprise Mobile Management n'est pas qu'une solution au problème posé par le BYOD et le CYOD. C'est aussi et avant tout une manière de répondre aux besoins de mobilité et de connectivité des collaborateurs d'aujourd'hui, en gérant efficacement les terminaux mobiles, smartphones et tablettes.

3.2 Le Cloud Computing et le Shadow IT : Le Cloud Computing peut se voir comme une évolution naturelle de l'infogérance (apparue dans les années 80) et de l'hébergement façon ASP ( apparu dans les années 90). La différence entre les deux modèles, ASP et SaaS, est d'ailleurs assez subtile : le mode ASP requiert généralement une instance dédiée de l'application pour un client donné, tandis que le mode SaaS autorise le partage de l'application par plusieurs clients différents (les données et les paramètres restant dédiés). Le mode SaaS s'appuyant par ailleurs généralement sur une offre IaaS ou PaaS, il s'adapte beaucoup plus facilement aux variations d'activités. Enfin, il s'appuie exclusivement sur les protocoles HTTP/S alors que le mode ASP autorise encore le client-serveur.

Parmi les nombreuses promesses du Cloud Computing et du mode SaaS, nous avons bien sûr la réduction des coûts par le partage des infrastructures et une plus grande automatisation,  une meilleure agilité du SI, le déploiement de nouveaux services se faisant plus rapidement, avec un time-to-market en phase avec les attentes et besoins de l'utilisateur, une meilleure flexibilité, les ressources informatiques étant mobilisées ou ré-allouées plus rapidement en cas de pic ou baisse d’activité. Tous ces avantages font que les DSI ont toutes plus ou moins adopté le Cloud Computing dans leur SI, que ce soit en mode privé, public voire hybride. Mais il y a une promesse qui, elle, gêne le DSI : celle de rendre les utilisateurs plus indépendants de l'informatique. Non pas que le DSI veuille maintenir ses utilisateurs dans un état de dépendance complète, loin de là. Mais pourquoi passer par son DSI quand on peut acheter directement, sans intermédiaire, un service informatique clé en main ? Je suis moi-même le premier à éviter les intermédiaires inutiles. On appelle ce phénomène de désintermédiation le Shadow IT. Et d'après une récente étude réalisée par PricewaterhouseCoopers, ce phénomène serait loin d'être négligeable puisque 15 à 30 % des dépenses informatiques des entreprises sondées se ferait hors budget DSI. Et cela n'est pas sans danger pour l'entreprise. Car le Shadow IT, s'il répond aux besoins des utilisateurs sur le moment (et c'est là son principal avantage), aboutit à un SI complètement éclaté, avec des risques importants de fuite de données, des difficultés d'intégration (il faut faire communiquer plusieurs fournisseurs), des données incohérentes, des risques de non réversibilité (les contrats étant mal voire pas négociés), et des coûts cachés importants. Un SI difficile à faire évoluer et dont la pérennité est mise en cause.

Pour lutter contre ce phénomène, il n'y a pas de miracle.

Premièrement, la DSI doit augmenter son implication auprès des métiers, mieux intégrer les enjeux de l’entreprise et faire évoluer son catalogue de services en anticipant les besoins de ses utilisateurs.

Si le DSI est perçu comme un homme de dialogue et de bon conseil mais qui a, comme tout le monde, des problèmes de ressources et de budget, alors les utilisateurs seront moins tentés de le court-circuiter. Et pour devancer les demandes de ses utilisateurs, rien ne vaut la proximité et la connaissance intime des métiers. Mais cela ne suffit pas. Pour proposer des évolutions pertinentes, il faut aussi comprendre les impacts du numérique sur le marché de son entreprise. Comme par exemple le phénomène du sur-mesure de masse. Les constructeurs automobiles, pourtant hautement industrialisés et automatisés, ont saisi cette opportunité offert par le numérique : après la voiture personnalisable (le consommateur choisit sa couleur de toit, de rétroviseurs et ses options, soit donc le sur mesure de masse), nous sommes vite passé à la voiture "sur mesure" individuelle. Ainsi Opel offre, à travers 3 univers et plusieurs packs, 80 000 combinaisons de son Opel Adam (Le Parisien évoque même 1 million). Objectif : donner à l’automobiliste le sentiment qu’il achète, voire « cocrée», un véhicule unique à son image. Cette approche nécessite des outils de personnalisation (un configurateur extrêmement bien pensé) et une chaîne logistique extrêmement performante et reconfigurable capable de soutenir la diversité des produits et services.

Deuxièmement, Il faut sensibiliser les métiers aux risques de pertes de données confidentielles et leur faire prendre conscience de la valeur des données qui circulent. Les exemples du programme de surveillance PRISM de la NSA, du piratage de France Télévisions ou celui du site de rencontres extra-conjugales AshleyMadison devraient aider les DSI et les RSSI...

Enfin, la DSI peut travailler sur sa propre organisation et ses méthodes, pour accélérer la mise en production de nouvelles fonctionnalités, intégrant les composantes du Cloud et les transformant en opportunité plutôt qu'en les considérant comme une menace.

Plusieurs voies s'offrent aux DSI :

• Adopter des méthodes agiles ou encore plus modernes des méthodes DevOps. Ce terme barbare est la contraction de Développement et Opérations. DevOps fait à la fois évoluer les processus de développement et de mise en production, et l'organisation en rapprochant les équipes de développement et de production. La méthode marie développements agiles (Kanban, Scrum) à des processus intégrés et outillés de livraison continue.
  Devops est un concept censé rapprocher le monde des études de celui de la production ; D'un coté, le monde des études, orienté utilisateurs et clients, projets, méthodes agiles. Pour répondre aux exigences des métiers, les développeurs accélèrent de plus en plus la fréquence des mises en production. De l'autre, le monde de la production,  qui gère toutes les activités de maintien en condition opérationnelle. Ce monde est bien connu et formalisé au sein des entreprises, avec des structures, des processus ITIL rodés et optimisés.

  Attention, DevOps n'est cependant pas la réponse à tout. Certaines architectures, trop monolithiques, ou avec des dépendances applicatives trop importantes, ne se prêtent pas à ce genre de concept. Et rapidité ne va pas toujours de paire avec fiabilité. Les solutions informatiques matures ont elles aussi leurs avantages : elles sont maîtrisées, ont été renforcées, leurs bugs ont été corrigés, elles disposent d'une sécurité et d'une conformité élevées, ainsi que de plans détaillés concernant leur évolution et leur maintenance.
  
  

  	Informatique traditionnelle	DevOps
  Principaux avantages	Stabilité et fiabilité, évolutions planifiées et contrôlées (roadmap)	Augmentation des fréquences de déploiement (time to market) et Amélioration de la qualité logicielle
  Principaux enjeux	Optimisation des coûts de fonctionnement	Optimisation de la valeur ajoutée et de l'expérience utilisateur
  Référentiels IT	Cycle en V (Dév) et ITIL (Ops)	DevOps
  Fréquence de déploiement	Semestrielle ou annuelle	quotidienne ou hebdomadaire
  Maturité	Maturité élevée	Encore expérimentale chez de nombreuses entreprises
  Environnements techniques préférentiels	Mainframe ou Unix, langage Cobol	Environnements virtualisés, Containers (type Docker), langage Java
  Architecture type	ERP (type SAP), Application monolithique, avec façade (ou pas) de Web Services, dépendances fortes entre applications	Applications modulaires, Micro services, indépendance des modules et services

   

•  La DSI peut également transformer son centre informatique interne sur le modèle du Cloud Computing privé. Avec pour objectif de s'adapter rapidement à la demande pour répondre aux besoins de l'entreprise et de réduire le délai d'adoption des technologies. Il lui faudra alors mettre à la disposition des utilisateurs un portail en libre-service qui permettra de provisionner et décommissioner des ressources ou des services, sur la base de ce fameux catalogue de services. Avec si possible une grille tarifaire simple, fonction du nombre d'utilisateurs, du nombre de CPU allouées ou de l'espace de stockage demandé.

  En poussant le modèle, on peut imaginer des DSI louant une partie de leur centre informatique sous-utilisé, ou a contrario achetant des ressources virtuelles supplémentaires en débordement. Ce qui nous amène à la 3ième voie.

• La DSI peut également s'orienter vers un rôle d’ensemblier, intégrant les services des différents fournisseurs Cloud. Elle garderait ainsi la vue globale du SI et serait garant de la cohérence et de la sécurité des données. C'est la DSI as a Service, qu'on appelle en bon français la DSI, courtier de services Cloud. Une personne de confiance qui, en conformité avec les normes de l’entreprise, aiderait ses directions métiers à trouver le bon fournisseur et intégrant les différentes offres du Cloud public, hybride ou privé.

Laquelle des voies choisir ? Difficile à dire : en matière de méthodes et d'organisation, il n'existe pas de solution universelle mais des réponses adaptées au cas par cas, fonction de la taille de l'entreprise, de ses enjeux et de sa maturité en matière de numérique. La réponse est sans doute qu'il faut savoir utiliser les 3 à bon escient : le DevOps permet de déployer des logiciels de meilleure qualité, plus vite, mais la méthode a besoin du cloud pour pouvoir provisionner les environnements nécessaires aux tests et recettes, et comme la DSI ne peut pas tout développer, il faut savoir intégrer les services tiers du Cloud. Mais le rôle de la DSI comme "simple" fonction de courtier me parait réducteur voire dangereux à terme pour la DSI et l'entreprise.
 

La DSI doit donc favoriser l'émergence des outils collaboratifs, permettant les échanges internes et externes, le travail en mobilité (encore et toujours), la rédaction des documents à 4 mains, le partage des connaissance, à travers des communautés virtuelles au sein desquelles les personnes peuvent échanger à titre privé ou professionnels des conseils, des trucs et astuces, des suggestions d’amélioration, bref innover. Bien sûr, ce domaine dépasse le simple périmètre de la DSI, qui ne voit souvent dans les RSE et le collaboratif qu'un projet visant à mettre en oeuvre un outil de plus. Projet voué à l'échec si pris sous cet angle.

Si l'entreprise veut attirer les talents de demain, ceux de la génération Y et Z, il faut aussi qu'elle puisse répondre aux aspirations de ces "digital natives".  Le collaboratif et l'innovation sont des facteurs importants de la culture du numérique : selon l'enquête Deloitte Millenial Survey 2014,  78% des digital natives considèrent l’innovation comme un facteur discriminant de leur motivation. Et même si le partage de connaissance et l'échange informel ne conduisent pas nécessairement à l'innovation, ils la favorise. Ainsi, Google permet à ses employés de consacrer 20% de leur temps à des projets "personnels". Et cela marche puisque cette liberté laissée aux "Googlers" a permis de faire naître des produits comme Gmail ou AdSense, ou encore Google Actualités et Google Earth (parait-il). De son côté, le français Gandi laisse une semaine par an à ses salariés pour innover en toute liberté : c'est la "Free Week", organisée avec un esprit communautaire et participatif. On peut aussi citer Atlassian et son Fedex Day, basé sur le même principe, ou Netflix, qui promeut une culture numérique basé sur la liberté (vacances illimitées) et la responsabilité (toujours agir dans l'intérêt de Netflix).

Je lis souvent que la génération Y détient la clé du numérique. C'est vrai et faux à la fois : elles ont la capacité d'utiliser les nouvelles technologies de manière innée, pour autant, elles ne savent pas nécessairement conduire une réflexion stratégique sur ces outils et la façon de créer de la valeur. Cette compétence reste, heureusement, ouverte à toutes les générations.

Même si la DSI n'est pas la seule responsable de l'innovation de l'entreprise, elle doit donc y contribuer fortement en dialoguant avec les directions métiers, en favorisant l'émergence de nouvelles technologies, en encourageant les expérimentations (et donc en acceptant aussi les échecs). Innover ou mourir, ce refrain est non seulement valable pour nos entreprises, elle est aussi valable pour les DSI.

La nécessaire transformation de la DSI

Vous l'aurez compris, à l'heure de la transformation digitale de l'entreprise, la DSI n'échappe pas à la règle et doit elle aussi réinventer son rôle et sa mission. Elle pourrait sinon disparaitre comme bon nombre d'entreprises, victime d'immobilisme...Car comme l'a dit si bien Confucius il y a fort fort longtemps, "Celui qui ne progresse pas chaque jour, recule chaque jour."

Parmi mieux s'en convaincre, rappelons-nous ceux qui ont "refusé" de changer et ont finalement "disparu", on peut citer :

• Digital, n° 2 mondial des constructeurs informatiques derrière IBM, qui n'a pas su adopter les standards du TCP/IP, de l'interopérabilité et des PC

• Novell, n°1 mondial du serveurs de réseaux locaux, fortement concurrencé sur son cœur de métier par Windows NT et Linux

• Nokia, n° 1 mondial des téléphones portables, qui a raté la vague des smartphones et vendu son activité à Microsoft.

• Kodak, n° 1 mondial de la photographie, qui même s'il a vu venir l'appareil photo numérique (Kodak a mis au point en 1975 le premier prototype d'appareil photo numérique) n'a pas su transformer son métier à temps...métier qui consistait à vendre de la pellicule photo argentique.

La DSI doit évoluer : pour cela, elle doit bien sûr s'outiller pour répondre aux nouveaux besoins de mobilité, aux phénomènes de BYOD ou CYOD. Elle doit aussi convertir les menaces en opportunités : utiliser à son profit plutôt que freiner l'adoption des nouvelles technologies, tels que le Cloud et le SaaS, tirer partie des avantages qu'offrent les containers (virtualisation des environnements accélérant le déploiement des applications) et le Cloud en mode IaaS ou PaaS (provisionning automatisé des ressources, élasticité des infrastructures, variabilité des coûts). Mais elle doit aussi transformer son organisation et ses méthodes, innover, expérimenter à travers de nouveaux modèles comme DevOps, tout en maintenant son informatique traditionnelle à un haut niveau de fiabilité. Car tout le monde n'a pas la chance de démarrer de zéro comme une start-up. Le mode agile serait ainsi réservé aux projets axés sur la différenciation et l’innovation, et le mode industriel dédié à la gestion des autres projets et à la maintenance du "legacy". Ce que le Gartner, toujours très fort pour inventer de nouveaux concepts, qualifie d'Informatique bimodale.

Et c'est là ou se joue probablement tout l'avenir : assurer une compatibilité et une intégration entre une informatique agile de type DevOps et une informatique traditionnelle incompatible avec ces nouvelles méthodes, et bien sûr, accompagner le changement. Sur ce dernier point, je vous conseille de jeter un œil à l'article de Mathias Moreau.