Ceci est le premier épisode d’une série d’articles décrivant des solutions simples que le cloud apporte à des problèmes compliqués auxquels j’ai été confronté dans ma carrière.

“Pourtant, ça marchait bien quand on l’a testé, et en prod ça ne marche pas !” (MJ, chef de projet, penaud et grosses cernes sous les yeux)

A combien de reprises ai-je été confronté à des mises en production chaotiques, parce que - quand on creuse pour trouver la raison principale - l’environnement sur lequel on a testé le système n’est pas exactement équivalent à la production ? En général, hors cloud, l’environnement sur lequel on teste une application n’est pas le même : il est a priori sous-dimensionné (parce que c’est moins cher) ; certains éléments d’infra sont simplifiés (règles de cloisonnement réseau plus limités car l’environnement n’est pas exposé à l’extérieur, autre stockage, clusters remplacés par des instances uniques…). Et en plus, ce sont parfois des organisations différentes qui gèrent ça (environnement de développement géré par des équipes hors prod, ou par des sous-traitants). Sans compter que la config réseau est gérée par l’équipe réseau, la config des pare-feux par l’équipe pare-feux, la config du SAN par l’équipe stockage…

Quand on monte une infra sur AWS, on peut gérer ça complètement différemment. L’outil vraiment épatant, c’est cloudformation. En un mot, c’est le fait de décrire son infrastructure dans un script, qu’on peut exécuter pour monter son infrastructure. C’est extraordinairement puissant. Il faut réaliser qu’on peut monter une infrastructure complète (config réseau, sécurité, base de données, stockage, cache, script de boot des serveurs, certificats SSL, répartition de charge, …) en définissant un script et en le lançant. Par exemple, pour construire un environnement de référence pour l’hébergement de wordpress avec haute disponibilité des frontaux et de la base répartis sur plusieurs datacenters, connexion SSL, CDN, cache, …, on peut trouver un script standard ici.

Et c’est là que ça trouve tout son intérêt : besoin de tester ? On fabrique l’infra de test le temps du test. Et on l’efface après. Même si l’infra est grosse, ça ne coûte presque rien, parce qu’on ne paye l’infra que le temps du test. Du coup :

• finie la galère de l’environnement de test qui n’est pas iso-prod. Copier, coller. Pas plus compliqué.
• et en plus, c’est moins cher ! au lieu d’avoir un environnement de test sous-dimensionné en permanence, on a un environnement de test parfaitement iso-prod, juste le temps du test.

Bon, on peut évidemment aller beaucoup plus loin, avec par exemple de l’intégration et de la mise en production continue, on aura l’occasion d’en reparler.

Durant mes études supérieures en école d’ingénieur, et dans mes premiers postes dans l’administration, on m’a toujours mis en avant les vertus de l’abstraction et de la compréhension des concepts pour être un “bon manager”. L’idée, c’est qu’au bout d’un moment, plus besoin de savoir faire soi-même dans le détail pour être capable de diriger, piloter. Diriger, piloter, devient une compétence à part entière, indépendante ou presque du sujet sur lequel on l’exerce.

Sans fondamentalement adhérer à ce point de vue, au fond, on se laisse entraîner, et progressivement, on s’éloigne de la compréhension intime des choses. Le premier qui a commencé à me mettre le doute, c’est Jacques Marzin. Quand j’étais à la DISIC (la direction interministérielle des systèmes d’information de l’Etat), il nous disait qu’il faudrait qu’on sache tous coder, qu’on ait tous un projet à côté, il nous parlait des difficultés qu’il avait à monter son cluster hadoop à la maison, … Je ne le prenais pas trop au sérieux, mais ça m’intriguait qu’un directeur expérimenté, qui avait un rôle très large avec un fort leadership sur toute l’informatique de l’Etat éprouve aussi le besoin de se confronter à la réalité.

Maintenant que je suis chez AWS, je réalise combien il avait raison. Dans l’informatique récente, il y a eu un nombre impressionnant de changements de paradigmes, qui finissent par perdre du sens à force d’être conceptualisés. Au bout d’un moment, le concept N+1 qui améliore le concept N qui avait supplanté le concept N-1, ça n’a plus beaucoup de sens, et on devient terriblement superficiel, à sauter d’un concept à un autre, à ne plus réellement distinguer le changement clé du buzz-word à la mode, et finalement ne plus vraiment comprendre précisément, intimement, le problème que chacune des évolutions résout.

Et je reconnais volontiers que malgré la curiosité que j’ai toujours entretenu pour la technologie, j’ai largement manqué certains virages. Et ça pose problème, parce que l’évolution technologique actuelle a introduit, et continue à introduire des transformations profondes, des ruptures, pas uniquement dans le “comment”, mais aussi dans les modèles économiques, les modèles d’organisation, les modèles d’achat, les modèles de sous-traitance.

J’ai donc (re)mis les mains dans le cambouis, et c’est un excellent moyen de comprendre vraiment comment le cloud marche et ce que la technologie change, en profondeur, dans le fonctionnement de l’informatique aujourd’hui. Et cette méthode est assez efficace pour comprendre plus “intimement” les qualités de sécurité, d’élasticité, de coût, … dans le cloud. Et de comprendre à la fois qu’il n’y a pas de magie (et oui ! le cloud, ça reste de l’informatique, il y a de la programmation, il y a des choses très techniques à faire), mais que c’est sensiblement plus simple que de configurer et gérer tout un tas d’infrastructures.

Combien de technologues parlent d’intelligence artificielle, sans avoir la moindre idée de comment ça fonctionne ? Et bien je pense que s’ils testaient Sagemaker, la plateforme d’IA d’AWS, comme je l’ai fait, on aurait beaucoup moins de fantasmes sur ce que c’est ou ce n’est pas, et sur le fait que si ça atteint des résultats extraordinaires aujourd’hui dans certains domaines, c’est le résultat d’un travail remarquable, qui fait appel à beaucoup d’intelligence humaine, et c’est très très loin d’être magique ; et réciproquement, ça reste quelque chose qui s’apprend, qui n’est pas fondamentalement inaccessible pour peu qu’on y investisse du temps.

Dans le même genre, n’hésitez pas à tester les services IoT, les services managés pour les containers, monter des architectures serverless… Dans ma to-do list, il y a encore une chose que je ne comprends que trop superficiellement : ce sont les blockchains ; ça tombe bien, j’ai de quoi faire aussi !

Fondamentalement, je vous encourage plutôt à essayer, à vous créer un compte plutôt que de continuer à lire ce post de blog… Tiens, en parlant de ce blog : une idée sur la façon dont il est fait ? J’ai commencé par me dire : allons sur un blog qui a déjà pignon sur rue (genre Medium). Je trouvais ça dommage de ne pas en profiter pour tester des choses par moi-même. Je me suis donc dit : installons ce blog sur AWS ; je me suis intéressé à l’architecture de référence pour héberger un site wordpress. C’était bien, efficace, avec un inconvénient tout de même : c’est surdimensionné pour un blog perso dont l’ambition reste modeste (avoir des frontaux redondés avec du partage de fichier, une base de données répliquée, du cache intermédiaire, c’était un peu exagéré). J’ai changé d’avis pour me diriger vers une architecture serverless pour la partie distribution du contenu. Comment ça marche ? Très simple : mes pages sont statiques, stockées sur S3, délivrées via cloudfront et route53 pour la gestion du nom de domaine. Les avantages sont nombreux : pas de serveur à gérer, à mettre à jour ; très très peu cher ; très scalable (on sait jamais !). Pour générer les pages, je m’appuie sur hexo, que j’ai installé sur un tout petit serveur EC2 que je n’allume qu’à chaque mise à jour de mon blog pour générer les nouvelles pages ; du coup, pareil, ce n’est pas cher, car ça ne fonctionne que très ponctuellement, c’est simple à sécuriser (au moment où je l’allume, je restreint l’accès à mon EC2 en SSH que depuis mon adresse IP, et je l’éteins ensuite…). J’ai choisi de ne faire que des pages statiques, mais on peut facilement les rendre dynamiques en ajoutant des appels d’API via du code javascript, comme sur cet exemple.

Rien de tel que d’essayer pour se rendre compte !

Le jour où je suis arrivé chez Amazon, j’ai été accueilli conjointement avec d’autres nouveaux arrivants de tous horizons, pas uniquement destinés à occuper un poste chez Amazon Web Services. Ce qui m’a marqué, c’est qu’il est clairement établi et pré-supposé que tout le monde, dans l’entreprise, est parfaitement à l’aise avec les outils informatiques du quotidien, depuis les assistants, les responsables RH, … Tout le monde.

On me dira que c’est trivial pour une entreprise comme Amazon Web Services. Oui, mais ce n’est malheureusement pas le cas dans les organisations publiques que j’ai connues précédemment. Et c’est un pré-supposé terriblement simplificateur. Chacun est censé savoir monter un VPN pour se connecter de façon sécurisée à distance. Chacun est censé savoir gérer ses sauvegardes dans son espace cloud personnel. Chacun est censé savoir configurer son smartphone pour accéder à la messagerie professionnelle. Chacun est censé savoir configurer son imprimante partagée. Etc. Bien sûr, chacun peut ne pas tout savoir, mais dans ce cas, la première chose qu’on nous donne à faire, c’est lire la doc sur l’intranet.
Au global, c’est drôlement efficace, car dans cet esprit, la plupart des besoins peuvent être couverts par du “self-service”, comme la réinitialisation des mots de passe ou l’installation d’un logiciel spécifique. On a même un distributeur automatique de “périphériques” (câbles, chargeurs, …)

Par rapport à ce que j’ai vécu dans mes précédentes fonctions, ça change bien des choses:

• tout le monde est logé à la même enseigne dans l’organisation. Vraiment. Pas d’imprimante individuelle dans des bureaux de chefs. Accès distant à la messagerie pour tous. Ordinateur portable avec accès VPN pour tous, et donc télétravail occasionnel possible pour tous. Wifi corporate partout. Inutile de dire qu’il n’y a pas de directeur qui se fait imprimer ses mails ; alors que si, ça existe encore en 2019 dans l’administration, et ce n’est vraiment pas raisonnable.
• tout le monde utilise les outils de messagerie instantanée, de visioconférence, de documents partagés et co-élaborés tout le temps. C’est normal qu’à chaque réunion, il y ait du monde qui se connecte à distance (télétravail, site distant, …), … C’est très loin d’être généralisé dans l’administration. Le mail et la réunion présentielle restent les outils de collaboration quasi uniques.
• ça tire la dématérialisation complète des processus (tout doit pouvoir se faire de partout ; par exemple, notes de frais prises en photo pour le workflow de remboursement initié via une appli mobile). Il n’y a pas de parapheur. Personne ne vient en réunion avec un gros dossier papier. Jamais. En 9 mois chez Amazon Web Services, je n’ai rempli AUCUN formulaire papier, rien signé manuscritement, rien fait signer manuscritement. Même mon contrat de travail… A comparer avec la pile de parapheurs qu’il y a encore, en 2019, sur tous les bureaux des cadres de l’administration.

En terme d’efficacité collective et individuelle, de facilité de collaboration, de traçabilité de l’information, … c’est la nuit et le jour avec ce que j’ai connu. Je ne vois aucun obstacle infranchissable pour adopter cela massivement dans les organisations publiques. Oui, il faut investir un peu dans l’outil de travail des fonctionnaires (ordinateurs portables, wifi, outils collaboratifs). Oui, il faut absorber le déficit de formation. Oui, il faut imposer un niveau de compétence pratique numérique au niveau du recrutement et des promotions. C’est un changement crucial et particulièrement efficace pour transformer l’administration.

Après avoir travaillé pendant 16 ans - toute ma carrière - au service de l’Etat, mon passage chez Amazon Web Services n’était pas du tout la suite triviale.

J’ai eu envie, en ouvrant ce blog, de partager cette expérience particulière, celle de la découverte d’un monde différent (très différent !), et extraordinairement enthousiasmant.

Je partagerai parfois quelques découvertes managériales et organisationnelles, tout n’est évidemment pas applicable immédiatement et partout, mais cela mérite tout de même qu’on s’y penche sérieusement (je ne peux pas m’empêcher de penser quotidiennement à leur application dans le contexte public que j’ai connu).

Je partagerai surtout ce que j’apprends sur le potentiel du cloud. Je réalise, semaine après semaine, combien certaines des difficultés techniques que j’ai rencontrées, en tant que DSI de l’éducation nationale, ou comme responsable de la production informatique du ministère de l’intérieur, auraient pu être résolues plus rapidement, plus simplement, plus économiquement.

J’ai la prétention de penser que cette expérience peut intéresser le lecteur, qui, je l’espère, y trouvera une source d’inspiration.

Je suis volontiers ouvert aux échanges, n’hésitez pas à me contacter via linkedin, ce qui m’évite d’avoir à administrer un forum sur ce site.

Je suis Mathieu Jeandron, né le 13 août 1978. Pour mon parcours professionnel, voir mon profil linkedin .
Après 16 ans dans l’informatique de l’Etat en France, dont 3 ans directeur du numérique pour l’éducation au ministère de l’éducation nationale, je suis maintenant Principal solutions architect chez Amazon Web Services. Ce blog personnel raconte mon aventure !

Ce blog est un blog personnel, il m’engage, mais n’engage pas mon employeur Amazon Web Services.

Ce blog est un blog personnel, ce qui est écrit représente mon opinion personnelle et non celle de mon employeur, Amazon Web Services (AWS).
Ce blog est hébergé en France chez Amazon Web Services (à mes propres frais).
Il n’y a pas de cookies, pas de publicité, donc je n’ai pas besoin de solliciter votre consentement pour quoi que ce soit.
Je ne traite pas de données personnelles sur ce blog, si vous souhaitez interagir avec moi, vous pouvez le faire par exemple via des réseaux sociaux tels twitter ou linkedin.