Ce que signifie la transformation digitale – 5ème partie

Ce nouvel épisode de la série consacrée à la transformation digitale s’intéresse à la culture de l’ingénierie, et, plus particulièrement, comme on peut s’en douter, à celle de l’ingénierie numérique.

La vidéo ci-dessus, est probablement une de celles apportant l’éclairage le plus précis sur la nouvelle culture de l’ingénierie numérique. John Allspaw a travaillé pour Friendster, a dirigé l’équipe IT de Flickr de 2005 à 2010 (9 personnes pour passer de 2 à 5 milliards de photos en ligne sur ce site communautaire) et est aujourd’hui SVP Infrastructure & Operations chez le site de vente en ligne Etsy.com.

Pionnier de l’approche DevOps et de la Continuous Delivery, Allspaw décrit parfaitement dans cette vidéo les principes d’ingénierie à l’oeuvre chez ces entreprises phares du numérique. Le 1er billet de la série sur la transformation digitale avance comme hypothèse que LE logiciel de ces entreprises est la mantra exprimée par Eric Ries dans Lean Startup : Build, Measure, Learn ; cette présentation de Allspaw en est une parfaite incarnation.

Une culture de l’ingénierie très souvent à l’opposée de celles constatées dans nos DSIs qui sont pourtant elles aussi, soumises aux enjeux de cette transformation …

La transformation digitale vue de la DSI

Si l’on veut résumer, on peut avancer que l’enjeu de la transformation digitale pour nos DSIs est de passer de la gestion de systèmes d’information du 20ème siècle :

• fermés, avec des canaux d’entrée limités et peu d’interconnexions avec d’autres systèmes
• utilisés en heure ouvrables (20h sur 24)
• par des centaines voir des milliers d’utilisateurs (les employés)
• sur un seul type d’appareil (ordinateur)
• avec une faible contrainte sur la performance en termes de temps de réponse

à de la gestion de systèmes d’information du 21ème siècle :

• ouverts, avec de multiples canaux d’entrée et de nombreuses connexions avec d’autres systèmes
• accessibles en permanence
• par des dizaines de milliers, voir des millions d’utilisateurs (employés mais aussi clients)
• sur tous types d’appareils (ordinateur, tablettes, smart-phones)
• avec des temps de réponse et une usabilité comparables à celle des applications web publiques

Comment elles ont fait jusque là

Pour répondre aux exigences des SI du 20ème siècle, les DSIs se sont massivement organisées avec une approche analytique de l’ingénierie, directement héritée de l’industrie du bâtiment, héritage illustré par les intitulés MOA (maîtrise d’ouvrage) et MOE (Maîtrise d’oeuvre).

L’hypothèse sous-jacente est qu’ainsi elles auront un meilleur contrôle des coûts, une meilleure qualité de service et un meilleur respect des délais. Une hypothèse mise à mal dès lors que l’on se rappelle que développer un système numérique ce n’est pas exactement la même chose que construire un pont, comme l’explique Martin Fowler, un des pères du manifeste Agile.

Système fermé, système ouvert

Cela peut toutefois fonctionner. J’ai démarré ma carrière dans un environnement gros systèmes IBM (TPF) où l’approche analytique Waterfall (cycle en V) m’a régulièrement permis de livrer des projets dans les délais et budgets avec le niveau de qualité attendu.

Mais la différence essentielle est que l’on travaillait avec, ce qu’on appelle dans l’approche systémique, des systèmes fermés. L’ensemble des applicatifs s’exécutait dans un système homogène et cohérent qui maitrisait l’ensemble des contraintes liées à la sécurité, au réseau, à l’interface graphique, aux ressources systèmes, aux entrées-sorties, aux performances etc …. Au final, il avait peu d’inconnues, peu d’interconnexions avec d’autres systèmes et des cas d’utilisation prédictibles. En ce sens, il ne s’agissait pas à proprement parler de systèmes complexes.

Comment est organisée la nouvelle ingénierie numérique

Revenons à notre sujet initial : John Allspaw et sa perspective sur l’ingénierie et la résilience des systèmes. Je vais retenir cinq points essentiels de cette présentation :

1. Cela va mal se passer

Allspaw part du principe qu’il va y avoir un problème car dans ces systèmes complexes et multi-déterminés (dont l’humain fait partie) il est impossible de tout prévoir et de tout anticiper.  Cela va nécessairement mal se passer et il invite donc à se poser les questions suivantes :

• qu’est-ce qui peut mal se passer ?
• comment saurons-nous qu’il y a un problème (quel élément de mesure et de détection) ?
• comment allons-nous le corriger ?
• comment allons nous tirer des enseignements de ce problème.

2. Technologie limitée

L’architecture mise en oeuvre par Etsy nous est présentée comme commune, sans intérêt (Allspaw la qualifie de boring) pour bien insister sur le fait que l’enjeu d’innovation n’est pas sur la technologie mais, bien évidemment, sur le business et sur la valeur client.

En outre il insiste sur la volonté de limiter le nombre d’outils et de technologies car à mesure que ce nombre grandit, le risque de se retrouver face à des situations nouvelles face auxquelles on ne saura pas répondre (et impacter négativement ainsi notre MTTR) grandit lui aussi.

Lorsque je vois des DSIs baser des développements stratégiques sur des nouvelles technologies sur lesquelles elles ne disposent pas de recul que ce soit en termes de performance ou d’opérabilité, je me dis que nous sommes bien loin des standards de gouvernance numérique des géants du web.

3. Architecture challengée

Dans une société à la vision Franco-Française, l’architecte documente, documente, documente … Il est mis sur un piédestal. Ceci peut poser problème tant pour les relations avec ses collaborateurs, que lors des réunions avec les utilisateurs. (…) Dans la vision anglo-saxonne, il est un membre de l’équipe, il participe aux réunions des développeurs et au suivi des problématiques techniques journalières, n’a pas peur de mettre les mains dans le cambouis (…) ce qui lui permet d’adapter l’architecture choisie (Jérémy Jeanson)

Dans nos DSIs, si l’expertise technique de développement, de validation ou d’opérations est très souvent externalisée (un peu comme on sous-traite l’activité des manoeuvres sur le chantier), ce n’est pas le cas de l’architecture, jugée comme une compétence stratégique pour la gouvernance SI. Le point essentiel d’attention y est l’urbanisation (toujours ce même héritage), c’est à dire comment rationaliser l’organisation du SI pour que celui-ci soit cohérent et que chaque donnée et traitement soit au bon endroit.

Il est intéressant de mesurer dans la présentation de Allspaw la différence avec la posture de l’architecture dans les entreprises numériques. Tout d’abord, et c’est dans un des premiers slides : son soucis premier est la performance (Keep it fast). La raison est bien évidemment parce qu’il s’agit d’un point essentiel pour le client, utilisateur du site. Il est de peu de réconfort pour un client d’une application qui répond péniblement en 30 secondes de savoir que l’urbanisation du système présente des couplages faibles et que le système utilisé est aligné sur l’état de l’art de l’architecture SI.

Un second point très intéressant est que chez Etsy, les décisions d’architecture sont systématiquement challengées dans des sessions publiques. On retrouve ici une différence essentielle entre l’approche française et anglo-saxonne de l’architecture qui évoque ce billet particulièrement éclairant de Jérémy Jeanson dont est tirée la citation ci-dessus.

4. L’apprentissage par la mesure

On retourve ici la Mantra Build, Measure, Learn. Allspaw ne cesse d’insister sur le besoin de tout mesurer et tracer (logs).

Le SVP de Etsy.com explique comment les mesures, par boucles de rétroaction (autre principe fort de l’approche systémique), permettent l’apprentissage. Nous sommes ici avec cette approche scientifique, au coeur du principe lean. Une (mais pas la seule) des raisons qui rend l’approche lean tellement adaptée au monde du numérique.

Par ailleurs, je suis toujours étonné comme le principe de traces sur les systèmes de production (les logs) n’est que peu utilisé dans les DSIs que j’accompagne. Pas systématique, non standardisé, sans référence di temps d’éxécution ni d’identifiant permettant de suivre une transaction. Il s’agit pourtant d’une pratique essentielle dans la compréhension et la résolution de problèmes de production (et donc la réduction du MTTR).

5. MTTR Vs MTBF

Il s’agit selon moi du point essentiel, point auquel Allspaw qui a longuement étudié la résilience des systèmes, consacre une bonne partie de sa présentation. Il y a deux stratégies pour gérer la résilience d’un système : suivre l’indicateur mesurant le temps moyen entre chaque arrêt (le Mean Time Between Failure – MTBF) ou celui mesurant le temps pour rendre à nouveau le système opérationnel (Mean Time To Repair – MTTR).

En donnant une analogie automobile, la stratégie MTBF est celle de Rolls Royce : un véhicule parfait, qui coûte extrêmement cher mais ne tombe jamais en panne. D’un autre côté, la stratégie MTTR serait celle d’une Jeep : une voiture qu’une équipe peut démonter et remonter en 4 minutes.

Dans l’environnement particulièrement complexe de développement d’applications inter-connectées et utilisées par un très grand nombre d’utilisateurs, Allspaw insiste sur la pertinence du modèle MTTR. Il s’agit d’un élément essentiel de la culture numérique ; ainsi chez Basecamp (anciennement 37Signals) on parle d’un droit à l’erreur mais d’un devoir de réaction rapide. Cette approche permet d’éviter de se perdre en Analysis Paralysis, d’expérimenter rapidement et de mettre en place un robuste système organisationnel d’apprentissage collaboratif.

Transformation numérique et Culture ingénierie

Pour conclure, voici un tableau récapitulatif, nécessairement un peu caricatural, mais qui permet de donner un aperçu synthétique des différences essentielles de cultures d’ingénierie numérique, entre celle du 20ième siècle (analytique et héritée du bâtiment, potentiellement efficace sur des systèmes fermés) et celle du 21ème siècle (inspirée de l’approche systémique, adaptée aux systèmes ouverts et complexes).

On pourrait avancer que l’enjeu de la transformation numérique pour la culture de l’ingénierie consiste à passer des principes de la première colonne à ceux de la seconde.

Les 6 premières lignes du tableau sont davantage liées à l’organisation et au pilotage et répètent des points évoqué dans la 4ème partie de cette série. Les suivantes sont plus précisément liées à la culture de l’ingénierie.

	20ème siècle	21ème siècle
organisation	– MOA et MOE – Silos fonctionnels	– Equipe pluri-disciplinaire (DevOps)
équipe	– distribuée géographiquement	– co-localisée dans le même open space
intégration des activités	– projet ; pilotage incarné (chef de projet)	– flux ; géré par les personnes concernées, à chaque point d’intégration
suivi	– réunions longues et hebdomadaires	– réunions courtes et quotidiennes
communication	– asynchrone (mail) et protocolaire	– instantanée et de personne à personne
chaine de décision	– plusieurs niveaux hiérarchiques – rythme hebdomadaire	– équipe – rythme quotidien
qualité	– basée sur des processus prédéfinis – conformité des processus appliqués – qualité vérifiée en fin de chaîne	– qualité du code – tests automatisés permanents – boucle de feedback à chaque étape du processus
architecture	– éloignée de la réalité des projets – puissante – soucieuse d’urbanisation du SI	– intégrée aux équipes – challengée – soucieuse du temps de réponse
compétences de réalisation	– externalisées	– internalisées
stratégie de résilience	– optimisée pour le MTBF	– optimisée pour le MTTR
gestion de la connaissance	– structurée, dans des livrables et documents	– dans le code et les tests – non structurée, dans des plateformes collaboratives
expertise	– basée sur le savoir et les sachants	– développée par l’approche scientifique : hypothèse, mesure, apprentissage validé
innovation	– pilotée par la R&D et la technologie : études, conception …	– pilotée par le business : expérimentation
livraisons	– peu fréquentes (eg trimestrielles ou semestrielles) – de gros lots de fonctionnalités	– quotidiennes – micro changements
technologie	– la meilleure solution technique pour chaque problème – intégrer des nouvelles technologies dans le cadre de projets	– limiter le nombre de technologies pour en garantir la maîtrise. – n’utiliser que des technologies éprouvées
ergonomie	– effort négligeable	>10 % des budgets de développement
vision de la valeur	– plus de fonctionnalités (même si elles comportent des anomalies)	– plus de valeur métier et d’usabilité

Cet article est extrait de l’ouvrage #hyperlean – ce que signifie l’avènement du numérique