“La montée en puissance des méthodes agiles annonce-t-elle le déclin de l’architecture ?”

L’agilité sonne-t-elle la fin de l’architecture  ?

Les méthodes agiles sont de plus en plus présentes au sein des DSI et rendent parfois le positionnement du rôle d’architecte plus difficile. Les visions des uns et des autres étant très différentes. Les architectes se doivent d’avoir une vision à long terme en cohérence avec la stratégie de l’entreprise, au contraire les équipes agiles se doivent d’avoir une vision à court terme axée sur la livraison d’un produit. Les architectes auront tendance à produire des documents de référence au contraire des agilistes qui préféreront une documentation collaborative et limitée au strict essentiel.

Parfois les architectes considèrent les agilistes comme des amateurs, sans expérience et devant être circonscrit à des petites applications web. Parfois, les praticiens Scrum ou XP perçoivent les architectes comme des personnes rétrogrades. Des individus capables de concevoir une architecture rigide, une architecture complexe sans valeur métier. Et de produire une documentation massive qui amènera des fonctionnalités non utilisées.

Différents positionnements de l’architecte existent : inclus dans l’équipe, dilué dans l’équipe, en dehors de l’équipe. J’ai déjà vécu plusieurs de ces positionnements et aucun ne m’a convaincu ni  satisfait.

Est-ce que ces vues sont fondées ? Est-ce que ces différents points sont opposés, contradictoires ou complémentaires ? Comment réconcilier une vision d’architecture d’entreprise avec des développements agiles focalisés sur la livraison d’un produit ?

Il existe une voie possible et très intéressante : l’architecture agile. Mais avant d’en parler examinons deux situations différentes issues de mon parcours.

Retour d’expérience : opposition entre développement agile et architecture

Cette première expérience non concluante a fini par opposer le travail des deux départements. Comment en est-on arrivé à une situation ou deux équipes n’arrivent pas à travailler ensemble ? 

L’état des lieux de la DSI :

Un département d’architecture existant.

• Ayant pour objectif de produire une vision d’architecture pour l’entreprise à plusieurs années.
• Centré sur la production de livrable d’architecture, des documents de référence.
• Ayant peu de relation directe avec les équipes de développement.
• Travaillant plusieurs mois en amont sur les futurs applicatifs

Une nouvelle équipe de développement en cours de création.

• Ayant pour objectif la création d’une application (le produit).
• Centrée sur la production de code, à forte valeur métier.
• Ayant peu de relation directe avec l’équipe d’architecture.
• Travaillant sur un cycle de trois semaines sur leur applicatif.

Des actions malheureuses ont placé en opposition les visions portées par l’agilité et l’architecture :

• Séparer les équipes physiquement ;
• Réduire la communication au minimum ;
• Outrepasser les processus en place sans prévenir les acteurs ;
• opposer la documentation collaborative (wiki) aux documents de référence ;
• Dissocier les cycles hebdomadaires des équipes agiles du cycle annuel des architectes ;
• Disjoindre la vision à court terme de la vision à long terme. 

Le résultat de ces actions n’a évidemment pas aidé à améliorer la DSI. Elle n’a fait que renforcer les divergences entre les points de vue.

Les inconvénients de cette situation :

• Prendre en compte des besoins métiers trop tôt, qui seront remis en cause lors du développement. Les architectes assumant aussi le rôle d’AMOA pour la capture des besoins métiers ;
• Développer des fonctionnalités inutiles. Je ne sais pas si Google Documents a été développé en mode agile. Mais j’arrive à produire un article, à qualité égale, avec Google Document (qui comporte beaucoup moins de possibilités que Microsoft Word) ;
• Produire une documentation peu abordable et trop imposante. Autant j’adore ouvrir un roman de science-fiction comportant plusieurs centaines de pages, autant le même nombre de page détaillant des architectures fonctionnelles aurait plutôt tendance à me rebuter.

Mais cette situation n’amène pas que des inconvénients.

Les avantages de cette situation :

• les rôles sont clairs, les architectes conçoivent l’architecture, les équipes de développement développent. Si toutefois les équipes ne se disputent pas la conception de l’architecture applicative ;
• l’équipe de développement reste maître de ses choix (techniques ou fonctionnels), ce qui permet une plus grande implication donc motivation de ses membres ;
• la livraison du produit reste l’objectif majeur de l’équipe. Cet objectif n’est pas laissé pour compte au détriment de la réalisation des composants d’architecture.

Retour d’expérience : architecture diluée dans les équipes de développement

Cette deuxième expérience non concluante a fini par faire disparaître, non seulement le rôle d’architecte, mais aussi ses contributions. Comment en est-on arrivé à une situation ou l’architecture n’existe plus ?

L’état des lieux de la DSI :

Plusieurs équipes de développement (en mode agile) composent la DSI. Ces équipes sont petites (deux à quatre développeurs) et toutes ne possèdent pas de concepteur expérimenté permettant de remplir le rôle d’architecte. Celui-ci est banni, on ne parle pas d’architecture c’est quasiment un gros mot. Il n’existe pas d’architecture partagée, ni de roadmap, encore moins de vision. Le rôle est donc assimilé par l’équipe, voire même digérée (et donc inexistant) par certaines équipes. Les interactions entre les équipes étant faibles, il n’existe pas de partage de l’architecture. Certains composants ou services sont dupliqués et les impacts de modification de composant ne sont visibles que lors de la phase d’intégration.

Les inconvénients de cette situation :

• Pas de rôle clairement établi, la responsabilité est reportée sur l’équipe. Ceci peut être normal, voire conseillé dans certaines équipes. Mais lorsque les développeurs ont peu d’expérience et sont peu nombreux, la responsabilité disparaît tout simplement ;
• Du refactoring en masse. Pas le refactoring nécessaire à chaque sprint permettant d’améliorer le code, mais du refactoring qui oblige à interrompre un sprint afin de revoir en profondeur la conception ;
• des impacts suite aux modifications non anticipées et qui se dévoilent lors des mises en production.

Mais cette situation n’amène pas que des inconvénients.

Les avantages de cette situation :

• pas de documentation à réaliser donc gain de temps à court terme évidemment ;
• peu de conception applicative, la production de code reste focalisée sur la livraison des fonctions répondant aux besoins métiers ;
• des coûts de développement plus faibles sur le court terme. Un développeur débutant étant moins cher qu’un senior.

La voie du sage : l’architecture agile

S’adosser aux méthodes agiles permet aux architectes de concevoir une architecture, répondant aux besoins métiers, aux objectifs de l’entreprise, le tout délivré au juste moment.

Un architecte doit coopérer et quoi de mieux que les cérémonies Scrum pour établir desinteractions entre leurs méthodologies, leurs processus et les équipes agiles. Suite à ces interactions, leslivraisons des architectes devront s’adapter aux rythmes agiles.  Enfin, la communication est un des fondamentaux du rôle d’architecte. Autour de ces trois items, le travail de l’architecte et des équipes agiles prendra toute sa valeur et son utilité.

Interaction

• Planification initiale

Lors de la planification initiale, comme dans tous les projets, les architectes doivent :

• Faire les principaux choix logiciels et matériels ;
• Identifier les composants ou services réutilisables ;
• Générer des diagrammes de haut niveau ;
• Communiquer avec les acteurs du projet (métiers, développeurs, production) afin de recueillir leurs besoins généraux et partager avec eux les orientations prises.

• Storyboard et backlog

Lors de la définition des storyboards et du backlog, l’architecte fait partie des acteurs. De par sa compréhension des enjeux métiers et des contraintes (ou opportunités) techniques, l’architecte tient un rôle clé dans la définition des besoins.

• Participation au sprint

L’architecte se doit de coopérer fortement, avec l’équipe. Il doit comprendre les objectifs du sprint afin d’aider l’équipe de développement à définir les grandes lignes de la conception. Arrivé à ce point, l’architecte devient alors un contributeur clé,  localisé physiquement avec l’équipe, avec la co-responsabilité du travail à réaliser.

• Revue de sprint

La revue de sprint permet à l’équipe de présenter aux différents acteurs l’avancée du produit. L’architecte est partie prenante des acteurs. Il aura préparé en amont la revue de l’architecture grâce à la documentation itérative fournie par le projet. Chaque erreur ou omission sera corrigée dans le sprint courant ou le suivant limitant ainsi les dettes d’architecture.

Livraison

En plus, de ces différences interactions, l’architecte doit s’adapter et délivrer des éléments d’architecture en respectant les points suivants :

Décomposition des composants

En mode agile, inutile d’espérer produire les documents d’architecture avant le sprint zéro. À l’identique du Product Owner qui décomposent les besoins métiers en features puis en user stories, l’architecte doit identifier les limites des composants d’architecture. Ceci afin de permettre à l’équipe de s’assurer que la décomposition des besoins métiers respectent ses limites.

Contribution de l’architecture au backlog

Intégrer les user stories d’architecture au backlog nécessitera certainement beaucoup de conviction de la part de l’architecte. La valeur métier de celles-ci n’étant pas forcément établie par le Product Owner. Néanmoins, plusieurs solutions existent :

• Ouvrir un deuxième backlog spécifique aux users stories d’architecture.
• Intégrer les users stories au backlog du produit suite à une estimation de leur valeur métier avec le product owner.
• Noyauter les users stories existantes avec les demandes d’architecture.

Communication

Livrer c’est bien, communiquer en amont et lors des livraisons est primordial.

Toute documentation n’est pas superflue

Souvent un prototype peut suffire afin de valider l’architecture. Mais certaines circonstances amènent à décrire plus formellement l’architecture, par exemple, la communication vers d’autres entités de l’entreprise ou pour répondre aux réglementations externes.

La valeur de l’architecture

Je ne saurais vous dire combien peut vous rapporter une architecture, par contre je pourrais vous décrire une dizaine d’exemples de ce qu’il en a coûté de ne pas avoir d’architecture. Le plus dure est certainement de placer le curseur à sa juste valeur. Concevoir l’architecture sans tomber dans le piège de l’architecture parfaite.

Auto-promotion auprès du Product Owner

Le métier d’architecte inclus une grande part de communication et celle-ci va être cruciale vis-à-vis du Product Owner. En effet, celui-ci est le rouage entre les besoins métiers et le produit final. Il va donc falloir le convaincre de l’utilité et de la pertinence de l’architecture. Dans le cas contraire les travaux d’architecture auront toujours des priorités basses et ne seront donc jamais réalisées.

En finir avec cette opposition contre-productive

Agilité et architecture ne sont donc pas des ennemis. Vous vous en doutiez avant de commercer à lire cet article, j’espère vous avoir fourni quelques arguments pour vous en convaincre.

La conception top-down initiée par les architectes et la conception bottom-up conçue par les équipes agiles sont complémentaires et nécessaires afin de délivrer un produit conforme aux besoins, parfaitement intégré dans le SI et robuste sur le long terme. L’anticipation n’est pas interdite dans l’agilité comme l’adaptation doit être une nouvelle vertu de l’architecture.

Pourquoi est-ce à l’architecte de s’adapter aux méthodes agiles et non l’inverse ? Car c’est toujours la personne la plus souple, la plus adaptable qui survivra !

Références :

• Agility and Architecture: Can they Coexist?
• Agile Architecture Intercations
• Agile Enterprise Architecture

Articles sur le même sujet

• 01/12/2011 -- Mettre sa suite de tests au régime 5 mn par jour
  Le 11 janvier, à l'aube du 3ème anniversaire du Paris JUG, David Gageot a présenté, sous le titre “Comment j'ai mis ma suite de tests au régime en 5 minutes par jour”, son retour d'expérience sur les tests unitaires et sur la façon de les optimiser. David prend une situation fictive mais probable...
• 03/30/2012 -- SCRUMDAY 2012 : L’heureux gagnant de l’IPAD 3
  A l'occasion du SCRUMDAY 2012, NEOXIA organisait un jeu concours avec à la clé le nouvel IPAD ! Après le tirage au sort, qui s'est déroulé sur les lieux du SCRUMDAY, Thierry est l'heureux élu qui est venu récupérer son lot chez NEOXIA. Thierry étant architecte et coach agile, il y a  fort à parie...
• 03/09/2012 -- Dans la peau d’un Product Owner SCRUM
  Voilà plus d’un an et demi que je continue de me documenter sur les pratiques Scrum : lectures de plusieurs ouvrages de référence (The communication Gap, User stories applied, Agile Testing, Gestion de projets agiles, etc.), formation certifiante “Product Owner” en 2010 et spectatrice de divers évèn...
• 02/03/2012 -- Story Points : 5 minutes pour comprendre
  Qu’est ce qu’un story point? Un story point sert à estimer l’effort nécessaire à une équipe pour implémenter une fonctionnalité (story pour les intimes).Cette estimation prend en compte : l’effort pour le développement la complexité du développement Le risque / l’inconnu Par abus de langa...
• 01/18/2011 -- L’A.T.D.D : une approche efficace de développement logiciel
  L’ATDD est la contraction de Acceptance Test Driven Developpement (Pilotage par les tests métiers en français). Il s'agit d'une approche efficace de développement logiciel. Tout a commencé par des questionnements successifs en interne sur la démarche à adopter pour résoudre de gros problèmes méth...

Precise Pangolin

La dernière mouture d’Ubuntu, nommée Precise Pangolin sortira le 26 avril prochain. C’est une version majeure du fait de sa maintenance sur le long terme, prévue pour les cinq prochaines années.
Qui dit support à long terme dit peu de modifications en profondeur, mais comme dans toute nouvelle version d’Ubuntu de nombreuses améliorations sont néanmoins présentes.

La précédente version LTS date d’avril 2012, son support est assuré jusqu’en avril 2013 pour la version Desktop et avril 2015 pour la version Server. La version 12.04 sera elle maintenue jusqu’en avril 2017. Un cycle de développement et de support aussi précis que transparent dont devraient s’inspirer les autres éditeurs.

Peu de changements sur le noyau et la version Server

Cette version sera basée sur la version stable 3.2.14 du noyau Linux. Une revue “intensive” de la configuration du noyau Ubuntu a été effectuée, peut-être dans le but peut être d’en réduire la consommation électrique ?
OpenStack (la brique logicielle permettant la mise en oeuvre de cloud privé ou public) est mise à jour en version Essex 3. OpenStack qui a d’ailleurs aligné ses cycles de développement sur ceux d’Ubuntu.
Avec l’introduction de MAAS (Metal As A Service), cette version embarque un outil de déploiement et de supervision de masse du système Ubuntu Server, à destination des serveurs physiques. Créer et administrer un cloud privé ou public est l’objectif conjoint de MAAS et de Juju. Ces outils permettront d’administrer des serveurs physiques ou des instances virtuelles de la même manière.

Squid (le proxy) passe en version 3.

Une version Desktop qui s’améliore encore

L’amélioration principale de cette version s’appelle HUD (Head-Up Display) ou en français “affichage tête haute”. Elle permet de donner un accès plus facile aux différents menus applicatifs. Appuyez sur la touche Alt et entrez quelques lettres ou mots et les différents menus s’afficheront dans une liste. Un appui sur la touche Entrée exécutera l’action. Une nouvelle façon d’éviter de se perdre dans les menus et/ou de découvrir les fonctionnalités d’un logiciel.

Une nouvelle fonctionnalité qui tient ses promesses à l’usage et qui restera surtout pratique pour les logiciels peu utilisés comme ceux dont les menus ressemblent à des labyrinthes. Les prochaines versions devraient également pouvoir être commandées à la voix. À terme, HUD devrait remplacer les menus dans les applications Unity, si l’adoption par les utilisateurs est généralisée.

Le lecteur de musique par défaut redevient Rhytmbox, lequel intègre Ubuntu One music store. Avec des tarifs équivalents à ceux de l’iTunes store, celui-ci devient une alternative crédible.

La logithèque (Le software center) bénéficie elle aussi de plusieurs améliorations:

• Possibilité d’afficher des recommandations personnalisées
• Paiement par PayPal
• Démarrage et exécution plus rapide

Une nouvelle fonctionnalité Vie privée apparaît dans les paramètres système, ce qui permet de choisir la durée de conservation de l’historique au niveau du système. Elle permet aussi de ne pas enregistrer les activités sur différents types de fichier. En effet, le champ de bataille du droit à l’oubli ne se limite pas seulement à Internet puisqu’il s’étend aussi à nos systèmes d’exploitation.

En conclusion

Precise Pangolin est une version nécessaire de stabilisation après l’introduction du Cloud et d’Unity dans les versions précédentes mais sans apport de modifications majeures. Son auteur, Marc Shuttleworth a d’ailleurs baptisé cette nouvelle version d’un nom qui selon lui évoque la cohérence, la robustesse et la précision.

Rendez-vous le 26 octobre prochain pour la sortie de la version 12.10.

Références :

• Documentation Ubuntu Francophone
• Billet d’annonce de la version par Marc shuttleworth
• Le calendrier de la sortie de Precise Pangolin
• Release note beta 2

Pour aller plus loin :

• Head-Up Display
• Metal As A Service
• Juju

Articles sur le même sujet

• 10/19/2011 -- Sortie de Ubuntu 10.11 Oneiric Ocelot
  Comme tous les six mois, j’attends avec impatience la dernière version de mon système d’exploitation gratuit préféré Ubuntu. Celui-ci arrivera ce jeudi, comme prévu. Les dernières nouveautés annoncées m’intéressant, concerne la version Serveur et la version Desktop. Côté serveur : le datacenter...
• 09/02/2011 -- Amazon Private Cloud (VPC) : Tour d’horizon et nouveautés
  Depuis le mois d’août, la solution Virtual Private Cloud (VPC) d’Amazon Web Services (AWS) est sortie de sa phase béta. Virtual Private Cloud ? VPC est la promesse d’Amazon de fournir l’équivalent des possibilités réseau d’un datacenter physique dans son cloud. En clair, le but est de pouvoir ...
• 05/17/2011 -- Amazon Web Services (AWS) : Rétrospective à 2 ans (sur le terrain)
  Après plus de deux années de pratique du marché et de la plateforme Cloud/IaaS d'Amazon (AWS), nous souhaitions partager notre rétrospective de cette première phase d'adoption. Au delà des discours marketing et prospectifs sur le Cloud, il nous apparait intéressant de partager un retour du terrain. ...
• 03/15/2011 -- Migrez votre application ASP .Net sous Windows Azure
  La plateforme Windows Azure est l’offre cloud de Microsoft qui permet d'héberger et d'exécuter différents types d’applications et de services. Deux ans après son lancement, cette solution PaaS est, désormais, complète et propose des services de haut niveau. Il est donc temps de s'intéresser à la que...
• 11/29/2010 -- Microsoft Azure, le tour d’horizon
  Neoxia s'est rendu à Berlin pour suivre l'édition 2010 des Tech Ed Europe. Les Tech Ed, c'est 5 jours de conférences de haut niveau, dispensées par des évangélistes Microsoft sur les dernières nouveautés technologiques. Ces conférences s'adressent principalement aux développeurs, architectes et IT P...

Au début des années 2000, les entreprises ont utilisé le marketing online et construisaient leur image de marque sur la toile en investissant massivement dans leur site institutionnel. Cette e-reputation qu’elles contrôlaient de l’intérieur pouvait à loisir évoluer en fonction de nouveaux produits à mettre en valeur, de leurs innovations, influençant ainsi le public ou le consommateur dans son acte d’achat en mode push. Les retours éventuels des clients, souvent synonymes de réclamations, n’étaient considérées que de manière isolée.

Les sociétés mesuraient d’un côté le trafic sur leur site corporate, et l’évolution des commandes passées dans le temps, en collectant le maximum d’informations sur les segments de clients : c’est l’avènement du e-commerce. Progressivement dotées d’outils CRM (Customer Relationship Management) pour gérer cette relation client (GRC), les sociétés captaient les informations de prospects ou de clients, les traitaient et les analysaient, grâce à des bases de données ciblées. Ces outils permettent de mettre en place ou d’entretenir une relation durable avec les clients, en leur envoyant des messages personnalisés à grande échelle, par différents canaux (courriers, téléphone, sms, emails…).

L’arrivée du Web 2.0 a changé la donne : le consommateur du web est devenu plus exigent, et n’hésite plus à comparer les produits qualitativement, quantitativement, à échanger des avis au sein de plateformes communautaires…Paradoxalement, l’apparition des réseaux sociaux (Social networks) comme Facebook, Twitter, Youtube, Daily Motion, Linkedin, Viadeo, Flickr, Myspace, etc. a provoqué un désintérêt des consommateurs vis-à-vis des sites institutionnels classiques, dont la consultation a chuté ces dernières années.

Et pourtant, les internautes sont de plus en plus nombreux à rechercher de l’information, à donner leurs avis sur un produit, à noter les marques, se transformant en « consomm’acteurs ». Je ne parle pas seulement des cyberconsommateurs pour qui faire ses achats sur Ebay est devenu un réflexe, mais de toutes les catégories (80% de la population en France). Il ne s’agit plus seulement d’un public jeune, car certains réseaux sociaux privés ne sont constitués que de retraités…à l’origine de buzz dont l’effet peut être à la fois instantané et inéluctable pour la marque ou le produit ciblé. De même, l’interaction n’est plus seulement orientée vers les clients de l’entreprise, mais également vers les salariés eux-mêmes qui intègrent désormais la stratégie de communication.

Plus ou moins promptes, les entreprises doivent maintenant utiliser les réseaux sociaux pour communiquer. Pour faire preuve de compétitivité, les initiatives se multiplient pour communiquer différemment, notamment par des offres promotionnelles. Les plateformes communautaires peuvent se révéler une source d’information inestimable pour constituer ou enrichir ses bases de données clients.

Dans le secteur du transport aérien par exemple, la compagnie KLM a fait parler d’elle en lançant en décembre 2010 un vol régulier Amsterdam-Miami à la suite d’un pari lancé sur Twitter : un producteur et un réalisateur hollandais, qui souhaitaient assister à l’événement musical « Ultra Music Festival » à Miami, ont réussi à remplir un avion entier d’artistes, condition requise par KLM pour leur fournir un vol direct.

Plus généralement, la gestion de la relation client est amenée à connaître de profonds bouleversements depuis l’avènement des réseaux sociaux. En effet, les réseaux sociaux permettent le passage du CRM au SNM (Social Network Management), un modèle dans lequel un Community Manager supervise les échanges quotidiens sur internet, et assure le bon déroulement de la communauté en ligne. L’objectif est de créer du lien social autour d’une marque ou d’un produit par l’animation de cette communauté. Cette communication propagée rapproche l’entreprise de ses clients : on parle alors de Social CRM ou de CRM 2.0.

Les avantages du Social CRM pour l’entreprise sont  :

• elle est véritablement en relation directe avec sa cible, le « social customer »,
• elle peut identifier en temps réel les conversations qui la concernent,
• l’enrichissement des données clients a lieu en direct,
• son chiffre d’affaire en ligne est optimisé,
• le suivi au plus près de la réaction du marché et l’identification des tendances.

En réalité, le Social CRM ne remplace pas le CRM classique, car il ne vise pas à vendre ou à entretenir une relation commerciale, contrairement au CRM, mais à gérer la relation entre le client et l’entreprise sur un plan affectif. Les outils dédiés étendent les capacités de la CRM, en favorisant les interactions « many to many » entre l’entreprise et son écosystème (clients, partenaires…). Représentant seulement 5% des investissements du marché de la CRM en 2011, leur croissance évaluée à 40% devrait encore augmenter. 

Sources :

Les Echos (2010),http://archives.lesechos.fr/archives/2010/lesechos.fr/12/02/020975256272.htm

CIO Online.com, manifestation Our Social Times (2011) : http://www.cio-online.com/actualites/lire-social-crm-2011%C2%A0-ne-pas-confondre-fans-et-clients-4007.html

Le Nouvel Economiste (mars 2012) : http://www.lenouveleconomiste.fr/lesdossiers/art-de-vivre-et-aerien-low-cost-et-compagnies-traditionnelles-14068/

Measuring the Benefits of Social CRM : http://www.youtube.com/watch?v=4ocH7bUrxaM&feature=related

Rapport du Gartner sur le Social CRM / Spectrum Groupe (2011) : http://www.spectrumgroupe.fr/blog/rapport-du-gartner-sur-le-social-crm/

Pour aller plus loin :

Articles les plus commentés

• 06/07/2006 -- Si tu ne t’occupes pas de la base de données, la base de données s’occupera de toi …
  On peut lire ça et là, depuis un certain temps, que la base de données n'aurait aucune espèce d'importance. Il suffirait d'utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux. Pour le compte de ses clients, nos équipes ont effectué plusieurs...
• 01/14/2009 -- Réduire les stocks pour livrer au plus tôt
  Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement. Adoptons maintenant une démarche Lean, et regardons de plus près l'organisation de notre production de fonctionnali...
• 01/30/2009 -- PMBOK, le corpus des connaissances en management de projets
  Un bon chef de projet sait faire référence à des outils et méthodologies éprouvées. Le PMBOK (Project Management Body of Knowledge) est l’ouvrage de référence en gestion de projet, édité par le Project Management Institute (PMI)....
• 01/05/2007 -- Bases de données à haute volumétrie : comment faire ?
  C'est une forte tendance, les applications d'entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d'utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n'est clairement pas le SOA ou la...
• 09/16/2008 -- Le blog Neoxia cité par blogAngels
  Ça fait toujours plaisir ! Le blog Neoxia apparaît dans la liste des principaux blogs d'entreprise, publiée par blogAngels, le spécialiste français des blogs d'entreprise. Ayant, au fil du temps acquis aussi cette conviction, nous somme également heureux d'apprendre que le blog d'entreprise ser...

A l’occasion du SCRUMDAY 2012, NEOXIA organisait un jeu concours avec à la clé le nouvel IPAD ! Après le tirage au sort, qui s’est déroulé sur les lieux du SCRUMDAY, Thierry est l’heureux élu qui est venu récupérer son lot chez NEOXIA.

Thierry étant architecte et coach agile, il y a  fort à parier que cet IPAD participe à quelques Sprint dans les prochaines semaines …

A l’année prochaine pour un prochain SCRUMDAY et à bientôt sur les conférences FSUG.

Articles sur le même sujet

• 11/19/2010 -- Soirée du Scrum User Group (SUG) du 18 novembre
  Articulée autour de 3 présentations et d'un atelier, cette soirée du SUG organisée par Xavier de Microsoft dans les locaux de VALTECH fut encore très enrichissante. Ce second rendez-vous depuis la rentrée s'est ouvert avec le retour d'expérience de Martin Sudmann de chez Priceminister.com. ...
• 05/04/2012 -- Agilité et Architecture : les frères ennemis ?
  “La montée en puissance des méthodes agiles annonce-t-elle le déclin de l’architecture ?” L’agilité sonne-t-elle la fin de l’architecture  ? Les méthodes agiles sont de plus en plus présentes au sein des DSI et rendent parfois le positionnement du rôle d’architecte plus difficile. Les visions des ...
• 03/09/2012 -- Dans la peau d’un Product Owner SCRUM
  Voilà plus d’un an et demi que je continue de me documenter sur les pratiques Scrum : lectures de plusieurs ouvrages de référence (The communication Gap, User stories applied, Agile Testing, Gestion de projets agiles, etc.), formation certifiante “Product Owner” en 2010 et spectatrice de divers évèn...
• 02/03/2012 -- Story Points : 5 minutes pour comprendre
  Qu’est ce qu’un story point? Un story point sert à estimer l’effort nécessaire à une équipe pour implémenter une fonctionnalité (story pour les intimes).Cette estimation prend en compte : l’effort pour le développement la complexité du développement Le risque / l’inconnu Par abus de langa...
• 01/18/2011 -- L’A.T.D.D : une approche efficace de développement logiciel
  L’ATDD est la contraction de Acceptance Test Driven Developpement (Pilotage par les tests métiers en français). Il s'agit d'une approche efficace de développement logiciel. Tout a commencé par des questionnements successifs en interne sur la démarche à adopter pour résoudre de gros problèmes méth...

Comme l’année dernière, Neoxia sera présent cette année au Scrum Day 2012 en tant que sponsor et conférencier.

Nous vous invitons à venir nous retrouver sur notre stand tout au long de la journée pour échanger avec les consultants Neoxia sur les pratiques agiles, Scrum, XP, Lean, … mais aussi sur les technologies, l’architecture des SI, les projets … et quelques surprises que nous vous réservons à cette occasion !

Pour ma part, j’animerai une session sur le thème “15 jours pour construire son Plan de Release avec les serious games”, au cours de laquelle nous verrons comment les principes de l’agilité peuvent aider à la gouvernance des SI.

L’équipe Neoxia vous attend donc le 

mardi 27 mars 2012
de 9h à 19h

à l’Espace CAP 15
1/13 Quai de Grenelle
75015 PARIS

>> Inscription en ligne <<

Articles les plus commentés

• 06/07/2006 -- Si tu ne t’occupes pas de la base de données, la base de données s’occupera de toi …
  On peut lire ça et là, depuis un certain temps, que la base de données n'aurait aucune espèce d'importance. Il suffirait d'utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux. Pour le compte de ses clients, nos équipes ont effectué plusieurs...
• 01/14/2009 -- Réduire les stocks pour livrer au plus tôt
  Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement. Adoptons maintenant une démarche Lean, et regardons de plus près l'organisation de notre production de fonctionnali...
• 01/30/2009 -- PMBOK, le corpus des connaissances en management de projets
  Un bon chef de projet sait faire référence à des outils et méthodologies éprouvées. Le PMBOK (Project Management Body of Knowledge) est l’ouvrage de référence en gestion de projet, édité par le Project Management Institute (PMI)....
• 01/05/2007 -- Bases de données à haute volumétrie : comment faire ?
  C'est une forte tendance, les applications d'entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d'utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n'est clairement pas le SOA ou la...
• 09/16/2008 -- Le blog Neoxia cité par blogAngels
  Ça fait toujours plaisir ! Le blog Neoxia apparaît dans la liste des principaux blogs d'entreprise, publiée par blogAngels, le spécialiste français des blogs d'entreprise. Ayant, au fil du temps acquis aussi cette conviction, nous somme également heureux d'apprendre que le blog d'entreprise ser...

Avec 26 millions de tablettes vendues dans le monde et 1 milliard de smartphones, les outils nomades se sont imposés dans la sphère non seulement privée mais aussi professionnelle des individus. La question suivante se pose alors : En quoi les outils nomades transforment les usages et les comportements des salariés dans leur quotidien ?

Que sont les outils nomades ?

• Réticentes au départ, les sociétés ont intégré ces nouveaux périphériques dans leur stratégie numérique, ce qui s’est traduit d’ailleurs par une percée d’Apple dans le monde de l’entreprise.
• Dans un premier temps, les tablettes ont été utilisées pour des échanges en continu à destination de quelques “privilégiés”, puis les métiers, notamment de la communication et du marketing, se sont emparés de l’outil créant des applications dédiées aux clients (accompagnant ainsi la progression de la navigation des internautes à partir du mobile).
• Les écoles ou universités, dans le même temps, ont participé à ce mouvement en offrant à leurs étudiants des Ipads (comme il y a une vingtaine d’années quelques écoles de commerce se lançaient dans la fourniture d’un ordinateur portable dans le package du nouvel étudiant, ce qui était à la fois révolutionnaire et un attrait pour leur image). 
• Cette tendance a été naturellement suivie par une diffusion plus ou moins massive des ardoises numériques à usage interne (exemple : SAP voulant équiper ses 17 000 salariés).
• Quel que soit le secteur, le binôme outil et contenu s’inscrit dans la stratégie de l’entreprise numérique collaborative autour de quatre axes : l’efficience, l’attractivité, la capitalisation des savoirs, l’innovation.

Articles sur le même sujet

• 11/16/2010 -- HTML 5 : Ce que vous devez savoir (partie 1)
  Le HTML5 est un terme de plus en plus utilisé, vulgarisé par l’usage des mobiles et certaines démonstrations technologiques utilisant par exemple le ‘canvas’ : composant de HTML qui permet d'effectuer des rendus dynamiques d'images bitmap via des scripts. Il est en passe de devenir un élément incont...

Voilà plus d’un an et demi que je continue de me documenter sur les pratiques Scrum : lectures de plusieurs ouvrages de référence (The communication Gap, User stories applied, Agile Testing, Gestion de projets agiles, etc.), formation certifiante “Product Owner” en 2010 et spectatrice de divers évènements Scrum.

Aujourd’hui Product Owner (PO) missionnée au sein d’une DSI, j’aimerais revenir sur quelques épisodes marquants de ma vie scrumienne. 

Episode 1- Le budget, la psychose du PO

En principe, dans les pratiques Scrum, le produit applicatif se construit tout au long des cycles de développement (ou itérations) permettant d’implémenter en priorité les fonctionnalités à fortes valeurs métiers et de s’assurer de répondre aux besoins des utilisateurs en recueillant régulièrement leurs retours. Le changement n’est donc, pas seulement autorisé, il est le bienvenu.

En pratique, même si la conception applicative suit effectivement le rythme des itérations, il est difficile, dans un contexte d’entreprise standard, de s’éloigner radicalement du périmètre fonctionnel initial décrit pendant la phase de cadrage (avant l’itération 0). Le backlog est indirectement en cause.

En tant que PO, je dois suivre deux indicateurs et les communiquer aux instances de pilotage, à chaque fin d’itération. Le premier, relatif au produit, concerne la complexité et s’exprime en story points : complexité absorbée (points réalisés pendant l’itération) et complexité restante (points restants dans le backlog produit). Le second, relatif au projet, traite du budget et s’exprime en jours hommes : budget absorbé (jours-hommes utilisés pendant l’itération) et budget restant (jours-hommes disponibles pour le projet). C’est à ce moment précis que se développe ma schizophrénie.

Initialisé à la fin de la phase de cadrage, suite au recueil des besoins métiers,  le backlog décrit les fonctionnalités principales du futur produit. Outil névralgique du projet, il a 2 utilités principales :

• Pour les équipes décisionnelles, il permet de budgétiser le projet grâce aux estimations de chacune des taches (ou stories) qui le peuplent. Pour ce faire, est appliqué au nombre total de story points un ratio story points/jours-homme, calculé grâce à la vélocité moyenne des équipes de développement. Autrement dit, si le backlog contient 500 story points avec un rapport moyen de 2 points absorbés par développeur et par jour, le budget est de 250 jours-hommes. De ce point de vue, le budget est acté et fixé pour le projet !
   
• Pour les équipes opérationnelles, il permet d’établir le plan des livraisons à moyen terme et celui des itérations à court terme. De ce point de vue, les fonctionnalités du produit évoluent tout au long du projet : de nouvelles naissent, d’autres sont modifiées mais aucune n’est vraiment jamais remplacée voire supprimée. Cela s’explique par le fait que pendant le cadrage, le besoin est tout juste mesuré et certaines parties ne se révèlent qu’au dernier moment. En conséquence, mon backlog produit grossit sans réajustement budgétaire.

En tant que PO, j’hérite, donc, d’un budget qui n’est plus réel, et, qui constitue, malgré tout, 50% de mes indicateurs de pilotage.

En résolvant cette problématique par dichotomie :

• Le pire que je puisse faire est d’endiguer les évolutions du backlog …
• Le mieux, à présent ! Sensibiliser les directions métiers aux processus Scrum et les amener progressivement à utiliser les pratiques agiles dans leur activité de planification

Nous pouvons orienter progressivement les directions métiers dans cette direction grâce notamment à une relation de confiance. Pour y arriver, parmi mes autres responsabilités de PO, la plus importante est la garantie de leur construire le “bon logiciel”. Certaines méthodes existent mais une seule a réellement fonctionné pour moi. Mais ceci mérite d’être le sujet d’une toute autre histoire ……

Articles sur le même sujet

• 11/19/2010 -- Soirée du Scrum User Group (SUG) du 18 novembre
  Articulée autour de 3 présentations et d'un atelier, cette soirée du SUG organisée par Xavier de Microsoft dans les locaux de VALTECH fut encore très enrichissante. Ce second rendez-vous depuis la rentrée s'est ouvert avec le retour d'expérience de Martin Sudmann de chez Priceminister.com. ...
• 05/04/2012 -- Agilité et Architecture : les frères ennemis ?
  “La montée en puissance des méthodes agiles annonce-t-elle le déclin de l’architecture ?” L’agilité sonne-t-elle la fin de l’architecture  ? Les méthodes agiles sont de plus en plus présentes au sein des DSI et rendent parfois le positionnement du rôle d’architecte plus difficile. Les visions des ...
• 03/30/2012 -- SCRUMDAY 2012 : L’heureux gagnant de l’IPAD 3
  A l'occasion du SCRUMDAY 2012, NEOXIA organisait un jeu concours avec à la clé le nouvel IPAD ! Après le tirage au sort, qui s'est déroulé sur les lieux du SCRUMDAY, Thierry est l'heureux élu qui est venu récupérer son lot chez NEOXIA. Thierry étant architecte et coach agile, il y a  fort à parie...
• 02/03/2012 -- Story Points : 5 minutes pour comprendre
  Qu’est ce qu’un story point? Un story point sert à estimer l’effort nécessaire à une équipe pour implémenter une fonctionnalité (story pour les intimes).Cette estimation prend en compte : l’effort pour le développement la complexité du développement Le risque / l’inconnu Par abus de langa...
• 01/18/2011 -- L’A.T.D.D : une approche efficace de développement logiciel
  L’ATDD est la contraction de Acceptance Test Driven Developpement (Pilotage par les tests métiers en français). Il s'agit d'une approche efficace de développement logiciel. Tout a commencé par des questionnements successifs en interne sur la démarche à adopter pour résoudre de gros problèmes méth...

Qu’est ce qu’un story point?

Un story point sert à estimer l’effort nécessaire à une équipe pour implémenter une fonctionnalité (story pour les intimes).
Cette estimation prend en compte :

• l’effort pour le développement
• la complexité du développement
• Le risque / l’inconnu

Par abus de langage, on dit que le story point sert à estimer la “taille” d’une fonctionnalité.

Pourquoi estimer ?

Il n’existe pas d’unité de mesure de la “taille” d’une fonctionnalité; donc déterminer le coût d’une fonctionnalité nécessite forcément des estimations.

Comment estimer ?

Une estimation est souvent le résultat direct ou dérivé d’un calcul. Par exemple pour estimer le coût nécessaire pour peindre une pièce, il faut :

• chercher une grandeur de mesure (la surface d’une pièce dans notre exemple)
• estimer le coût en fonction de la surface et du coût par mètre carré

En l’absence d’une grandeur de mesure (comme pour les fonctionnalités), l’estimation peut se faire comme suit:

• chercher une unité de comparaison (une autre pièce de référence dans notre exemple)
• estimer le coût en fonction du coût de la pièce de référence multiplié par le rapport d’une pièce sur l’autre

L’estimation est donc relative, la rendant ainsi plus facile à réaliser.En effet, quand il s’agit d’estimer, il est plus facile de raisonner en relatif. Prenons une situation où il s’agit de déterminer le poids d’une boîte A. Pour garder l’analogie avec les tailles des fonctionnalités, disons que nous ne savons pas peser la boîte A. Dans ce cas là, c’est plus facile pour une personne de dire que la boite A pèse deux fois le poids de la boite B que de dire la boite A pèse 2,37 Kg.

Pourquoi ne pas estimer directement le temps nécessaire pour développer une fonctionnalité?

Pourquoi estimer la “taille” d’une fonctionnalité? Pourquoi ne pas prendre le temps comme unité de comparaison et faire des estimations relatives? Ce temps varie en fonction de la taille et de l’expérience de l’équipe. Prendre en considération l’expérience des membres de l’équipe permet d’obtenir des estimations plus fines et donc fiables. En revanche, cette prise en considération rend plus complexe le travail collégial d’estimation. Par exemple un développeur Junior peut estimer une tâche à 3 jours alors qu’un développeur avec plus d’expérience (ou plus ancien sur le projet) estimera la même tâche à une journée de travail.

Disposer d’une grandeur d’estimation qui soit propre à la story est donc nécessaire.

Ce raisonnement peut être retrouvé dans l’exemple suivant:

Combien de temps pour aller d’un point A à un point B ? : la réponse dépend forcément du moyen de transport et de sa vitesse (à pieds, à vélo, en trottinette, en fusée …). Pour avoir une réponse, il faut donc une estimation de la distance (en analogie avec la taille de la fonctionnalité). Ensuite, il suffit de calculer le temps nécessaire en fonction de la vitesse du moyen de transport.

La notion de “taille” d’une story est la grandeur propre à la fonctionnalité. Comme pour chaque grandeur, il y a besoin d’une unité de mesure et dans notre cas c’est le story point.  

Comment estimer en story points?

Pour pouvoir estimer en relatif, l’équipe commence par choisir une ou plusieurs stories de référence en leur attribuant arbitrairement et d’un commun accord une “taille” chacune.

Ensuite, lors de la réunion de Planning Poker (aussi appelée réunion de chiffrage, d’estimation ou encore de cotation):

• La nouvelle fonctionnalité est présentée.
• Les membres de l’équipe posent des questions pour avoir plus de précisions.
• Chaque membre de l’équipe estime la “taille” de la fonctionnalité relativement aux tailles des stories de référence.
• Les membres de l’équipe dévoilent en même temps leurs estimations pour ne pas influencer les votes.
• Si les estimations ne convergent pas, les membres de l’équipe expliquent les raisons de leurs choix
• Le processus d’estimation est répété jusqu’à ce que tous les membres de l’équipe se mettent d’accord sur une estimation.

Se mettre d’accord sur une estimation ne veut pas forcément dire que tous les membres votent pour la même “taille”. Il se peut qu’un des membres de l’équipe donne une estimation supérieure à celles des autres. Dans ce cas, après discussion avec l’équipe et avec l’accord de tous les membres, l’estimation la plus haute est retenue.

Quelle échelle d’estimation?

Plusieurs séquences existent pour estimer la “taille” d’une fonctionnalité. Les plus utilisées sont :

• séquence avec une taille numérique (varie de 1 à 10)
• séquence avec la taille des vêtements (XS, S, M, L, XL, XXL) (souvent utilisé en Kanban)
• séquence de Fibonacci (1, 2, 3, 5, 8, 13, 20, 40, 100) : séquence où chaque numéro est égal à la somme des deux numéros précédents.
• séquence (1, 2, 4, 8): séquence où chaque numéro est égal au double du numéro précédent.

Notons bien, que la séquence de Fibonnaci est un peu modifiée puisqu’à partir d’une certaine valeur la précision n’a pas beaucoup d’importance. Se baser sur des séquences non linéaires (comme les deux dernières) rejoint cette idée aussi et permet d’éviter de longues discussions autour de la “vraie valeur” de la taille d’une story. N’oublions pas qu’il s’agit toujours d’estimations.

Peu importe la séquence choisie, il faut que l’équipe se sente à l’aise avec celle-ci et qu’elle l’a conserve pour tous les chiffrages.

Comment déterminer les coûts de développement ?

Comment les estimations en story points peuvent nous aider à déterminer les coûts de développement des fonctionnalités? Pour le comprendre, il faut introduire la notion de vélocité.

La vélocité est une mesure de la capacité d’une équipe à réaliser des fonctionnalités sur une période donnée. Elle est calculée en sommant les story points des fonctionnalités terminées. Par exemple, une équipe qui termine le développement de deux stories estimées à 5 points et une story estimée à 3 points aura une vélocité de 13 points.

Ayant la vélocité de l’équipe, il est facile de déduire une estimation du temps nécessaire à partir de l’estimation des tailles des stories.

Conclusion

Ce billet de blog se concentre sur la technique d’estimation avec les story points. Cette technique n’est pas la seule, on peut citer l’estimation en jour idéal. En pratique, l’exercice d’estimation laisse place à différentes questions comme: que faire des stories non terminées à la fin des développements? quand réestimer les stories? comment estimer les stories quand on ne connaît pas la technologie ?

Articles sur le même sujet

• 01/18/2011 -- L’A.T.D.D : une approche efficace de développement logiciel
  L’ATDD est la contraction de Acceptance Test Driven Developpement (Pilotage par les tests métiers en français). Il s'agit d'une approche efficace de développement logiciel. Tout a commencé par des questionnements successifs en interne sur la démarche à adopter pour résoudre de gros problèmes méth...
• 05/04/2012 -- Agilité et Architecture : les frères ennemis ?
  “La montée en puissance des méthodes agiles annonce-t-elle le déclin de l’architecture ?” L’agilité sonne-t-elle la fin de l’architecture  ? Les méthodes agiles sont de plus en plus présentes au sein des DSI et rendent parfois le positionnement du rôle d’architecte plus difficile. Les visions des ...
• 03/30/2012 -- SCRUMDAY 2012 : L’heureux gagnant de l’IPAD 3
  A l'occasion du SCRUMDAY 2012, NEOXIA organisait un jeu concours avec à la clé le nouvel IPAD ! Après le tirage au sort, qui s'est déroulé sur les lieux du SCRUMDAY, Thierry est l'heureux élu qui est venu récupérer son lot chez NEOXIA. Thierry étant architecte et coach agile, il y a  fort à parie...
• 03/09/2012 -- Dans la peau d’un Product Owner SCRUM
  Voilà plus d’un an et demi que je continue de me documenter sur les pratiques Scrum : lectures de plusieurs ouvrages de référence (The communication Gap, User stories applied, Agile Testing, Gestion de projets agiles, etc.), formation certifiante “Product Owner” en 2010 et spectatrice de divers évèn...
• 10/04/2011 -- Croisière à la voile Vs Projet informatique : faisons le point
  J’ai pu cette année, après quelques années d’interruption, reprendre une de mes activités favorites : la croisière à la voile. Et cela s’est encore très bien passé. Merci à mes coéquipiers 1. Un programme défini en commun au début de la quinzaine puis respecté par la suite. Une adaptation journalièr...

Depuis maintenant plusieurs années, le Cloud Computing envahit la presse IT, les blogs, les plaquettes commerciales des éditeurs, intégrateurs et autres constructeurs en promettant pour ses clients de nombreux bénéfices parmi lesquels une optimisation de leurs dépenses et une adaptation plus rapide à leurs besoins réels.

Une autre transformation profonde de notre économie est son évolution vers des d’activités éco-responsables qui limitent la consommation de ressources naturelles et l’émission de gaz à effet de serre.

C’est dans le cadre de l’émission Green Business animée par Nathalie Croisé sur BFM Business qu’il m’a été donné de rapprocher ces deux sujets et de tenter de répondre à la question “le Cloud computing peut-il être vert ?” (écoutez le podcast).

Voici quelques éléments de réponse.

Les vertus écologiques du cloud computing repose sur 3 piliers :

• la virtualisation,
• la mutualisation,
• l’optimisation.

Virtualisation
On estime que le taux d’utilisation des serveurs déployés traditionnellement en entreprise est de l’ordre de 15%. Or l’usage des technologies de virtualisation permet de faire passer ce taux à 60 voire 80%, et ainsi de réduire d’un facteur 4 le nombre de serveurs physiques nécessaires à puissance de calcul comparable.
La réduction du nombre de serveurs physiques rendu possible par la virtualisation est le premier levier de réduction des émissions de CO2 apporté par le cloud computing. En effet, ce sont les phases de construction et de retraitement qui génèrent 70% des émissions de CO2 produites au cours du cycle de vie d’un serveur.

Mutualisation
Les opérateurs de cloud computing investissent dans la construction de datacenters qui sont des infrastructures techniques partagées sur lesquelles sont déployés les serveurs virtuels de leurs différents clients. Or chaque client possède son propre mode de consommation de ressources IT, et ils sont certes parfois concurrents mais souvent complémentaires entre eux. Par exemple, un e-commerçant pourra consommer beaucoup de ressources IT pendants la période de Noël alors que les clients entreprises seront généralement beaucoup moins actifs en cette période.
Ainsi, la répartition fine des ressources virtualisées sur des infrastructures physiques mutualisées permet d’augmenter le taux d’utilisation de ces dernières, générant par là même des économies d’énergie et des réductions d’émissions de CO2.

Optimisation
Du fait de son mode de consommation de ressources IT “à la demande”, le cloud computing est un secteur très concurrentiel, car les clients ne sont pas liés par des engagements à long terme et peuvent donc, assez facilement, changer d’opérateur.
Ainsi, pour demeurer attractifs, ces derniers doivent régulièrement, d’une part, améliorer leur offre de service, et d’autre part, maintenir des tarifs compétitifs.
Or, sur ce dernier point, la consommation énergétique des datacenters est un levier primordial puisque l’on estime que 70% du coût de fonctionnement d’un serveur provient de l’énergie nécessaire pour l’alimenter … et le refroidir.

C’est donc en cherchant à réduire la consommation énergétique de leurs datacenters que les opérateurs de cloud computing allient, selon un cercle vertueux, baisse des coûts et réduction d’émission de CO2.

Il n’est pas l’objet de cet article de présenter en détail les différents moyens d’optimiser la consommation énergétique des datacenters, néanmoins il demeure intéressant d’en connaître les principaux.

Réduire la consommation des composants

• CPU, mémoire : diminuer la fréquence d’utilisation, augmenter la finesse de gravure, …
• disques durs : utilisation de la technologie SSD, réduction de la vitesse de rotation des disques magnétiques, …

Réduire l’énergie nécessaire au refroidissement des composants

• améliorer l’efficience des système de climatisation : localisation au plus près des composants, utilisation de fluides au lieu de l’air, …
• augmenter les limites de température de fonctionnement,
• utiliser l’air extérieur (free cooling) efficace dès que la température descend sous les 13°

Améliorer l’efficacité énergétique globale des datacenters

Il s’agit globalement de minimiser la consommation d’énergie qui de concerne pas directement les composants actifs du datacenter que sont les serveurs, la climatisation, le stockage, …
Cette efficacité est mesurée par l’indicateur PUE (Power Usage Effectiveness) qui est le ratio entre l’énergie consommée par les composants IT et l’énergie globale consommée par le datacenter.
Souvent supérieur à 2 il y a encore 3 ans, ce ratio est descendu sous les 1,2 en 2011 pour les datacenters les plus efficients.

Virtualisation, mutualisation, optimisation de la consommation énergétique des datacenters permettent, à ressources IT comparables, de réduire significativement la consommation d’énergie et les émissions de gaz à effet de serre associées. Faut-il pour autant en conclure que le cloud computing n’a que des vertus d’un point de vue écologique ?

La situation n’est pas aussi simple et le cloud computing doit faire face à 2 principaux reproches :

• il favorise la demande de consommation de ressources IT,
• ses principales sources d’énergies sont non renouvelables et génèrent massivement des émissions de CO2.

Le cloud computing accroît la demande de consommation de ressources IT
De par les nouveaux usages qu’il permet, de consommation “à la demande” de services numériques, qu’ils soient personnels ou professionnels, le cloud computing tire de manière très importante la consommation de ressources IT à des niveaux que l’on aurait difficilement imaginés quelques années plus tôt.

Ainsi, même si unitairement, ces ressources sont plus économes en énergie et donc en émission de CO2, d’un point de vue global, la consommation augmente !

Sur ce sujet, l’exemple de Facebook est significatif.
Début 2010, par la mise en oeuvre de la technologie HipHop, Facebook a pu diviser par deux le nombre de serveurs nécessaires à ses 400 millions d’utilisateurs de l’époque. Mais à fin 2011, le nombre d’utilisateurs de Facebook dépasse les 800 millions et depuis deux ans, de nombreuses fonctionnalités nouvelles comme la vidéo ont accru la consommation de ressources du premier réseau social mondial.

Il faut cependant noter que dans certains cas, cette consommation nouvelle de ressources IT peut être bénéfique, par exemple lorsqu’elle permet d’éviter un voyage en voiture ou en avion pour une réunion qui se tient par visio-conférence.

Cela étant dit, il paraît évident que la consommation de ressources IT, porté par la numérisation de notre économie et aidée par le modèle du cloud computing, va continuer de croître dans le futur. Aussi, les mesures de réduction de l’empreinte écologique du cloud computing vont devoir porter sur les sources d’approvisionnement des datacenters.

Les principales sources d’énergie des datacenters sont aujourd’hui non renouvelables
Gros consommateurs d’énergie électrique, les datacenters sont contraints d’adopter les sources d’énergie disponibles dans leur région d’implantation, à savoir des sources carbonées (charbon, gaz, pétrole) majoritaires au niveau mondial (60%) ou nucléaire (15%) contre .

Néanmoins, les opérateurs de cloud computing ne restent pas inactif sur ce point et les plus avancés en la matière poursuivent deux options, souvent en parallèle :

• la compensation de leur émissions de CO2 par l’investissement dans des sources d’énergies renouvelables :
• envisage la construction d’une ferme photo-voltaïque de 69 hectares pour compenser l’émission de CO2 de son datacenter de Maiden en Caroline du Nord ,
• investit 100 millions de dollars dans une ferme éolienne en Oregon
• l’utilisation par leurs datacenters de sources d’énergie renouvelables :
• construit son futur datacenter européen (Suède) près d’une centrale hydro-électrique ,
• alimente l’un de ses datacenters avec les chutes du Niagara ,

En synthèse, que pouvons-nous conclure du caractère “green” du cloud computing ?

Je vous propose d’en retenir trois points :

• le processus “virtualisation, mutualisation, optimisation” est vertueux et permet, dans la durée, de réduire la consommation marginale des ressources IT et les émissions de CO2 associées, pour le bénéfice des consommateurs et de la planète,
• la numérisation de l’économie permet de remplacer des usages très consommateurs en énergie par des usages numériques plus économes, mais ces derniers rendent inéluctable l’accroissement de la consommation des ressources IT, qui aujourd’hui repose encore trop sur des sources d’énergie non renouvelables,
• l’effet d’échelle apporté par les datacenters du cloud computing permet d’envisager dans les années à venir de réels progrès vers un cloud plus vert !

Articles les plus commentés

• 06/07/2006 -- Si tu ne t’occupes pas de la base de données, la base de données s’occupera de toi …
  On peut lire ça et là, depuis un certain temps, que la base de données n'aurait aucune espèce d'importance. Il suffirait d'utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux. Pour le compte de ses clients, nos équipes ont effectué plusieurs...
• 01/14/2009 -- Réduire les stocks pour livrer au plus tôt
  Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement. Adoptons maintenant une démarche Lean, et regardons de plus près l'organisation de notre production de fonctionnali...
• 01/30/2009 -- PMBOK, le corpus des connaissances en management de projets
  Un bon chef de projet sait faire référence à des outils et méthodologies éprouvées. Le PMBOK (Project Management Body of Knowledge) est l’ouvrage de référence en gestion de projet, édité par le Project Management Institute (PMI)....
• 01/05/2007 -- Bases de données à haute volumétrie : comment faire ?
  C'est une forte tendance, les applications d'entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d'utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n'est clairement pas le SOA ou la...
• 09/16/2008 -- Le blog Neoxia cité par blogAngels
  Ça fait toujours plaisir ! Le blog Neoxia apparaît dans la liste des principaux blogs d'entreprise, publiée par blogAngels, le spécialiste français des blogs d'entreprise. Ayant, au fil du temps acquis aussi cette conviction, nous somme également heureux d'apprendre que le blog d'entreprise ser...

Nous vous proposons de retrouver en vidéo les meilleurs extraits de la conférence “Entreprise numérique collaborative” du 24 mars dernier organisée l’Association des anciens  du MSIT avec le soutien du CIGREF, du groupement « HEC Economie Numérique et Internet -Entreprises » et le club Mines Informatique, Colt et Neoxia.

Avec la participation de :

• Monsieur François Blanc (Group Director, Information Systems Valeo)
• Monsieur Stéphane Hugon (Co-fondateur et dirigeant d’Eranos, docteur en sociologie)
• Monsieur Jean-Marc Lagoutte (CIO de Danone et Vice-Président du CIGREF)
• Monsieur Bruno Ménard (Vice-Président – SI de Sanofi-Aventis, Président du CIGREF et de la Fondation CIGREF)
• Monsieur Gilles Mergoil (Co-fondateur et Président de Neoxia)
• Madame Béatrice Rollet (Directrice Solutions chez Colt CES)

Cette manifestation a été animée par Monsieur Frédéric Simottel (Rédacteur en Chef de 01 Informatique).

Merci aux personnes ci-après qui ont contribué à l’organisation et ont permis la tenue de cette conférence.

• Fabrice PERRIN - Président de l’Association des anciens du MSIT; http://www.msit.org
• Denys JOURDANT- Co-organisateur de la conférence et des cercles de réflexion, Membre du groupement HEC Economie Numérique et Internet – Entreprises  -
• Florence DIETSCH - Co-organisatrice de la conférence et des cercles de réflexion, Membre du groupement HEC Economie Numérique et Internet- Entreprises
• Alain MOSCOWITZ - Président du Club Mines Informatique - http://www.mines-paris.org/
• Pierre-Laurent DUGRÉ - Vice-Président du groupement HEC Economie Numérique et Internet- Entreprises

Articles les plus commentés

• 06/07/2006 -- Si tu ne t’occupes pas de la base de données, la base de données s’occupera de toi …
  On peut lire ça et là, depuis un certain temps, que la base de données n'aurait aucune espèce d'importance. Il suffirait d'utiliser un mapping objet/relationnel et de se reposer sur un mythique cache, sorte de panacée à tous les maux. Pour le compte de ses clients, nos équipes ont effectué plusieurs...
• 01/14/2009 -- Réduire les stocks pour livrer au plus tôt
  Dans l’épisode précédent, nous avions livré une première fonctionnalité après 245 jours. Et nous nous étions mis au défi de livrer cette même fonctionnalité bien plus rapidement. Adoptons maintenant une démarche Lean, et regardons de plus près l'organisation de notre production de fonctionnali...
• 01/30/2009 -- PMBOK, le corpus des connaissances en management de projets
  Un bon chef de projet sait faire référence à des outils et méthodologies éprouvées. Le PMBOK (Project Management Body of Knowledge) est l’ouvrage de référence en gestion de projet, édité par le Project Management Institute (PMI)....
• 01/05/2007 -- Bases de données à haute volumétrie : comment faire ?
  C'est une forte tendance, les applications d'entreprise opèrent sur des volumétries de données de plus en plus grandes. Qui plus est, une pléthore d'utilisateurs et de clients accèdent à ces données, que ce soit directement, ou, le plus souvent, indirectement. Et ce n'est clairement pas le SOA ou la...
• 09/16/2008 -- Le blog Neoxia cité par blogAngels
  Ça fait toujours plaisir ! Le blog Neoxia apparaît dans la liste des principaux blogs d'entreprise, publiée par blogAngels, le spécialiste français des blogs d'entreprise. Ayant, au fil du temps acquis aussi cette conviction, nous somme également heureux d'apprendre que le blog d'entreprise ser...