Les fonctions de hachage, expliquées simplement

Sans les fonctions de hachage, pas de sécurité sur Internet, ni de blockchains, ni de signature électronique. C’est une des briques fondamentales de la sécurité en ligne. Mais qu’est-ce que c’est une fonction de hachage ? Et à quoi servent-elles ?

Une fonction de hachage, c’est un peu comme un hachoir à viande, mais pour les données. Dans un hachoir à viande, vous pouvez mettre du bœuf, du poulet, du porc… vous obtiendrez toujours la même chose : de la viande hachée.

• 🐄 ➔ 🥩
• 🐓 ➔ 🥩
• 🐖 ➔ 🥩

Dans une fonction de hachage, vous pouvez mettre n’importe quel texte, vous obtiendrez toujours la même chose : du texte illisible (appelé empreinte ou hash)

• Longtemps je me suis couché de bonne heure ➔ F151075AF003B1E0D5E80147DBF14DAE
• Longtemps je me suis couché 2 bonne heure ➔ DAB780064C91AA5A4D93DA6BC34245E9
• gm ➔ 92073D2FE26E543CE222CC0FB0B7D7A0

Quand vous avez de la viande hachée, vous ne pouvez pas « dé-hacher » la viande. C’est pareil pour les fonctions de hachages : vous ne pouvez pas revenir en arrière et retrouver les données initiales. Ça ne fonctionne que dans un sens.

La seule manière de retrouver un message à partir de son empreinte, c’est de tester plein de messages en espérant tomber sur la même empreinte. Ça s’appelle une attaque par force brute et ça porte plutôt bien son nom : c’est très long et très coûteux.

Pourquoi ? Parce que les fonctions de hachage sont bien faites. En regardant les exemples proposés plus haut, on voit en effet que :

• en changeant un seul mot (deux qui devient 2), on obtient une empreinte complètement différente (ça s’appelle l’effet avalanche ❄️)
• quelque soit la longueur du message d’entrée, l’empreinte est toujours de la même taille 🐾

Mais au final, pourquoi transformer de la belle prose en une vilaine chaîne de caractère ? Parce que ça permet de faire plein de choses pardi ! Prenons les mots de passe par exemple : ils ne sont pas stockés tel quel sur Internet. Ils sont hachés avant d’être enregistrés : azerty123456 devient E4B4C6324ED01B8EDF3139C32C413C00. Ainsi, personne ne peut connaître votre mot de passe, même pas la personne qui gère la base de données dans laquelle il est sauvegardé.

Et quand vous voulez vous connecter ? Rien de plus simple : vous tapez votre mot de passe, il est haché, et si son empreinte est la même que l’empreinte enregistrée vous pouvez entrer. Parce qu’une autre propriété des fonctions de hachage est qu’elles sont déterministes : le même message produit toujours la même empreinte. C’est pour celà qu’on les utilise aussi pour la signature électronique ou pour vérifier qu’un logiciel téléchargé n’a pas été modifié.

Enfin, les fonctions de hachage sont très rapides à calculer. C’est pour cela qu’on les utilise dans les blockchains. En effet, on a besoin de s’assurer que l’historique des transactions n’a pas été changé. Pour cela, à chaque bloc de transaction, on calcule une nouvelle empreinte à partir du bloc et de l’empreinte du bloc précédent. N’importe qui peut donc vérifier que rien n’a été changé dans l’historique des transactions très rapidement : il suffit de recalculer les empreintes successives, ce qui est beaucoup plus rapide que de vérifier une à une toutes les transactions.

Cinq choses que j’ai apprises en lançant l’incubateur du ministère des Armées

J’ai quitté le ministère des Armées la semaine dernière. J’y ai passé trois ans et j’y ai beaucoup appris. Notamment cinq leçons que je voulais partager ici. Rien de révolutionnaire, c’est surtout du bon sens. Mais le quotidien nous fait parfois oublier le bon sens.

«L’échec n’est pas une option »

À mon arrivée, c’était la devise de la DSI à laquelle j’étais rattaché. Je voyais cette phrase tous les matins et je me disais que ce n’était pas gagné. En effet, je venais pour lancer l’incubateur du ministère des Armées. L’objectif ? Développer des produits numériques pour l’ensemble du ministère, en utilisant les méthodes à l’état de l’art dans les startups : agile, lean startup, DevOps…

Leçon n°1 : il faut la bonne équipe. J’étais seul au départ. Seuls, nous allons plus vite. Mais il n’y a qu’en équipe que nous pouvons construire des produits d’envergure. J’ai donc consacré beaucoup d’énergie à recruter des développeurs, des designers et des product managers pour avoir la bonne équipe. Une bonne équipe, c’est un mélange. Un mélange d’expertise technique et de qualités humaines, comme l’humilité, la curiosité ou l’autonomie. Mais l’ingrédient magique qui permet à des personnalités différentes de s’entendre, c’est une culture partagée.

Leçon n°2 : il faut la bonne culture. Pour recruter des personnes exceptionnelles alors que rien n’existe, il faut d’abord établir une vision claire de là où nous voulons aller. C’est cette vision qui m’a permis de les convaincre de rejoindre l’aventure. Au fur et à mesure, nous avons étoffé cette vision de nouvelles valeurs et de nouveaux principes. Quand de nouvelles personnes nous rejoignaient ou que nous apprenions de nouvelles choses sur notre environnement. J’ai déjà beaucoup écrit à propos de cette culture : se concentrer sur les problèmes, parler aux utilisateurs, avoir de l’autonomie… Elle nous a unis et nous a permis d’avancer dans la même direction. Grâce à la culture, tout le monde prend les bonnes décisions, sans carotte ni bâton.

Leçon n°3 : il faut savoir persister. La culture permet également de garder le cap quand les choses prennent du temps. Elles peuvent en prendre dans une organisation de presque 300 000 personnes… En 2017, j’imaginais qu’un logiciel développé par une administration pourrait être utilisé par d’autres, en SaaS. En 2020, nous avons vendu la première « licence » du logiciel de recrutement que nous avons développé. Niveau DevOps, nous avons mis au point une chaîne d’outils solide sur Internet. Sur l’intranet du ministère des Armées, c’est une autre histoire. Le chantier débute seulement malgré le lobbying que j’ai commencé dès mon arrivée. Pour les idées qui valent la peine, il faut être patient, ou plutôt persistant. Agir dès maintenant et continuer jusqu’à ce que notre vision se concrétise, même si cela prend des années.

Leçon n°4 : il faut aussi savoir arrêter. À l’inverse, il y a des choses qu’il faut accepter d’arrêter. C’est difficile quand nous sommes passionnés. Mettre à la poubelle ce que nous avons passé du temps à construire ? Plus facile à dire qu’à faire. Je me suis par exemple battu pour qu’un de nos produits continue alors qu’objectivement il aurait mieux valu l’arrêter (et sans doute même ne jamais le commencer). Je me disais que nous étions si près du but qu’il était dommage d’arrêter. Sauf que le produit a continué à nous prendre bien plus de temps et d’énergie que prévu. Pour lutter contre cela, mieux vaut agir à tête reposée, avant même de commencer quoique ce soit. Quand nous avons encore de la volonté. Avec des règles simples mais strictes (comme refuser les produits que personne ne portent) et des critères d’arrêt définis à l’avance (par exemple un nombre minimum d’utilisateurs atteint après un certain temps), il est possible de lutter contre notre aversion aux coûts irrécupérables (sunk cost fallacy).

Leçon n°5 : il faut beaucoup communiquer. Enfin, j’ai appris que sortir de bons produits ne suffit pas. Au lancement de la Fabrique numérique, j’ai fait le choix de construire avant de communiquer. Faire des produits, plutôt que des annonces. Le problème c’est qu’en se concentrant trop sur les produits, il est facile d’oublier la communication. J’aurais dû y mettre plus d’énergie afin que plus de gens nous connaissent. Sur le long terme, c’est un élément clé. La communication, qu’elle soit externe pour se faire connaître, ou interne pour aligner les équipes est un élément fondamental.

Une bonne équipe. Une bonne culture. Persister ou arrêter. Communiquer. Des choses simples mais dont il faut se rappeler au quotidien. Voilà ce que j’ai appris, ou révisé, pendant ces trois ans. Merci à celles et ceux qui ont partagé ce bout de chemin avec moi.

–

PS : je vais arrêter pendant quelque temps de publier du contenu, le temps d’apprendre de nouvelles choses que je pourrai partager. À très vite !

À périmètre variable

« Cela va durer six mois, vous aurez un super produit, mais nous ne savons pas encore quelles fonctionnalités il y aura dedans… »

C’est ce que nous disons au lancement des nouvelles startups d’État. Pour ceux qui sont habitués à rédiger des cahiers des charges cela fait tout drôle. D’habitude, ils donnent une liste de fonctionnalités à un prestataire qui va développer en respectant « les coûts et les délais », et livrer un produit pas terrible. Sauf qu’il faut souvent payer encore un peu plus, parce qu’il y a eu des imprévus.

De la même manière que les physiciens savent qu’il y a un lien entre la température, la pression et le volume d’un gaz parfait (à quantité de matière constante), les habitués du développement logiciel savent qu’il y a une relation entre la qualité, les délais et le périmètre d’un projet (à coût constant). Ainsi, si les délais et le périmètre sont fixés, c’est forcément au détriment de la qualité.

Nous faisons donc le choix (et nous ne sommes pas les seuls) de construire des produits selon des standards de qualité élevés, et dans des délais serrés. La seule solution pour réussir à faire cela, c’est de rendre le périmètre variable. De limiter le nombre de fonctionnalités que nous allons livrer.

L’avantage, c’est que limiter le périmètre initial est une bonne chose. En effet, nous n’apprenons qu’en faisant. Avec de vrais utilisateurs. En testant des hypothèses en conditions réelles. N’est-ce pas la base de la méthode scientifique ? Ceux qui affirment pouvoir tout anticiper sont au mieux naïfs.

Et vous, quels paramètres considérez-vous comme variables ou fixes ?

Via negativa

Dans son livre Antifragile, Nassim Nicholas Taleb présente le concept de via negativa : mieux vaut chercher ce qui peut être retiré, plutôt que ce qui peut être ajouté. Pour les problèmes de santé mineurs par exemple, il est plus prudent d’arrêter certaines choses (les aliments trop riches, la cigarette, etc.) que d’en introduire de nouvelles, comme les médicaments. En effet, ces derniers peuvent avoir des effets indésirables, alors qu’arrêter ce qui nuit améliore la santé sans conséquences négatives.

Pour chaque bénéfice, il faut considérer le risque associé. L’ajout, la via positiva, introduit systématiquement de la complexité, de l’imprévisible. L’ajout augmente le risque. Au contraire, la suppression simplifie, limite les effets secondaires, épure. La suppression diminue le risque.

Les grandes organisations comme l’administration gagnerait à passer un peu plus de temps sur cette voie négative. À réfléchir à ce qu’il faudrait supprimer. À simplifier. À refactoriser ce qui peut l’être, plutôt que de créer sans cesse de nouvelles structures ou de nouveaux règlements. Mais niveau communication, ce sont toujours les créations qui sont mises en avant, jamais les simplifications.

Ce concept s’applique également dans nos vies de tous les jours : plutôt que d’ajouter des choses censées nous rendre plus heureux, pourquoi ne pas nous concentrer sur la suppression de ce qui nous rend malheureux ?

« Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher. » (Antoine de Saint-Exupéry)

Urbanisation et innovation : deux forces en tension

Les grandes organisations ont désormais toutes besoin de logiciels internes pour fonctionner. Quand arrivent de nouveaux besoins, deux forces sont alors en tension : l’urbanisation et l’innovation.

Le but de ceux qui urbanisent ? S’assurer que chaque besoin est satisfait par exactement un logiciel. Sans urbanisation, c’est rapidement le chaos. Les employés ont trente moyens différents de stocker leurs documents, et personne ne retrouve plus rien. Mais si trop de pouvoir est laissé aux urbanistes, les évolutions peuvent devenir trop lentes et tout le monde est frustré.

Le but de ceux qui innovent ? S’assurer que les nouveaux besoins qui apparaissent sont satisfaits. Sans innovation, c’est rapidement la déprime. Les employés utilisent chez eux des applications qui sont belles et agréables, et tout le monde souhaite avoir la même chose au travail. Mais si trop de pouvoir est laissé aux innovateurs, les évolutions peuvent devenir trop rapides et tout le monde est perdu.

Comme beaucoup de choses dans la vie, il s’agit de trouver un équilibre entre ces deux forces.

Une première forme d’équilibre, c’est celle où chacun campe sur ses positions : les urbanistes font tout pour bloquer les nouveautés ; les innovateurs produisent des choses dans leur coin en cachette.

Un meilleur équilibre est celui où tout le monde échange : les urbanistes réservent aux innovateurs une place dans leur plan pour laisser ces derniers mener des expériences ; les innovateurs prennent en compte les contraintes existantes et ne réinventent pas la roue quand elle existe déjà.

Une histoire lean (2/2)

La semaine dernière, j’évoquais dans cet article l’histoire de NUMMI, une usine de construction automobile gérée par Toyota et General Motors (GM). GM découvrait alors la recette magique permettant de décupler la qualité de ses voitures. Cependant cette nouvelle méthode n’a pas été généralisée. Nous allons découvrir ici pourquoi.

La première raison, c’est qu’une transformation lean doit être globale, sur toute la chaîne de valeur.

Les employés de GM ayant visité les usines japonaises dans les années 1980 se sont toujours demandés pourquoi Toyota était si transparent. Jusqu’à ce qu’ils réalisent bien plus tard que faire du lean va bien au-delà des usines. Cela nécessite d’avoir un système où tout le monde va dans la même direction.

À NUMMI par exemple, la majorité des pièces proviennent du Japon et sont de bonne qualité. La pratique de l’amélioration continue fait que s’il y a un problème avec une pièce, le problème remonte et est résolu. Tout le monde travaille ensemble.

Au sein de GM par contre, tout est compartimenté. En silos. Chaque département « balance par-dessus le mur » ce qu’il a produit et passe à autre chose. La méthode Toyota ne peux donc pas fonctionner dans l’environnement GM. Même quand les équipes des chaînes de production mettent toute leur bonne volonté, certains problèmes restent insolubles à cause du manque de collaboration. De quoi ruiner le moral de tout le monde…

La seconde raison, c’est qu’une transformation profonde nécessite un sentiment d’urgence.

Une usine détenue par GM, celle de Van Nuys, va tester le système Toyota. Contrairement à l’usine de Fremont, cette dernière n’a jamais été fermée. Et personne ne croit aux menaces de fermeture. Les employés sont formés en deux semaines et la mayonnaise ne prend pas. Le nouveau système est vu comme une menace. Les salariés et le management refusent en bloc la méthode. L’usine Van Nuys finit par fermer et plus de deux milles personnes perdent leur emploi.

De manière plus générale, le groupe ne se transforme pas car ses ventes diminuent de manière progressive. Jusqu’au choc. En 1992, l’entreprise fait plus de vingt milliards de dollars de perte. Le nouveau PDG impose alors la méthode Toyota au groupe. Au début des années 2000, ce changement est enfin en place et GM produit des voitures de la même qualité que Toyota. Sauf qu’il est trop tard.

Le constructeur fait faillite en 2009. General Motors se retire de NUMMI. Toyota ferme l’usine. Tesla la rachète l’année suivante, pour y construire ses premières voitures électriques. La fin d’une époque ; le début d’une autre.

Une histoire lean (1/2)

Ce passionnant épisode du podcast This American Life raconte la transformation ratée de l’industrie automobile aux États-Unis. Peut-être y a-t’il des enseignements à tirer de cette histoire.

Celle-ci débute à Fremont en Californie. L’usine General Motors (GM) locale est l’une des pires au monde. Elle produit des voitures de très mauvaise qualité. Les ouvriers boivent pendant leur travail. Le dialogue social est extrêmement conflictuel. L’usine finit par fermer en 1982.

Deux ans plus tard, Toyota, qui a besoin de s’implanter aux États-Unis, rouvre l’usine en créant une joint venture avec GM. L’usine est renommée NUMMI : New United Motor Manufacturing Incorporated. Tous les ouvriers sont envoyés au Japon pour être formés et vivre le système de production Toyota (précurseur du lean manufacturing). Sur place, les ouvriers travaillent en équipe et améliorent constamment leur manière de faire.

NUMMI sort sa première voiture en décembre 1984. Le niveau de qualité est incroyable. Égal à celui des usines japonaises. Mais le plus incroyable, c’est que 85 % des employés sont les mêmes qu’avant la fermeture. Devant un tel succès, que pouvait faire GM sinon appliquer cette nouvelle méthode à toutes ses usines ? Ils venaient de trouver la recette miracle.

Sauf que ce n’est pas ce qui s’est passé. GM ne s’est mis au lean que 20 ans plus tard et a été déclaré en faillite en 2009. Évidemment, le maintien de l’ancien mode de production n’est pas la seule raison de sa faillite. Mais cela y a quand même contribué.

Pourquoi le système Toyota ne s’est-il pas diffusé ? Réponse la semaine prochaine, dans la seconde partie de cet article !

Faire un bon produit nécessite d'être connecté à ses utilisateurs

Cette année, je suis monté à bord d’un avion militaire pour voir comment des utilisateurs se servaient d’un des produits développés à la Fabrique numérique. Utiliser un logiciel dans un avion, ce n’est pas la même chose que dans un bureau. Le débit internet est pourri. Ça bouge dans tous les sens. Il n’y a pas de souris… Même si nous pouvons tenter d’imaginer à quoi ça ressemble, il n’y a qu’en le vivant qu’il est possible de vraiment ressentir les contraintes.

Ce que j’entends, je l’oublie. Ce que je vois, je le retiens. Ce que je fais, je le comprends.

Vous vous souvenez de Captain Train ? C’était une startup qui vendait des billets de train et qui a été rachetée depuis. L’expérience utilisateur était exceptionnelle par rapport à ses concurrents. Tout était simple. Rapide. Efficace. Évidemment, cela est dû à une multitude de facteurs. Mais je suis persuadé qu’un tel niveau de qualité est lié à cela :

« Tous les salariés de l’entreprise (qu’ils soient développeur, marketeur, comptable ou CEO) font une après-midi de support par mois. » (extrait d’un article de l’ancien responsable du service client chez Captain Train)

Chaque employé de Captain Train était connecté aux utilisateurs. Sans filtre. En direct. Comment faire un mauvais produit dans ces conditions ? Quand vous savez qu’une fois par mois, vous allez devoir gérer vous-même les clients, cela vous pousse forcément à essayer de régler les problèmes avant qu’ils n’arrivent !

À l’inverse, combien de services de l’administration sont tellement mal conçus que c’est à se demander s’il y a une équipe produit et si celle-ci a déjà parlé ne serait-ce qu’à un seul utilisateur ?

Ce n’est pas la faute des gens qui les produisent. C’est le résultat d’une organisation où tout fonctionne en silo, où les responsabilités sont diluées, où l’externalisation est parfois poussée à l’extrême.

Les choses évoluent néanmoins, avec par exemple l’observatoire de la qualité des démarches en ligne lancé en 2019 qui permet aux usagers de noter les services publics numériques qu’ils utilisent. Cependant, tant que les cultures produit et design ne se seront pas largement diffusées dans l’administration, nous serons condamnés à mettre dans des avions (et ailleurs) des produits dont nous n’aurons jamais vu, ni écouté, les utilisateurs.

Écouter ses utilisateurs, ce n'est pas faire un cahier des charges.

Lorsque nous expliquons que pour construire nos produits nous allons faire de la recherche utilisateur, certains nous répondent :

« Ah oui, vous allez écrire un cahier des charges… ».

Non ! Développer un produit avec ses utilisateurs n’a rien à voir avec rédiger un cahier des charges. Un cahier des charges n’est rédigé qu’une seule fois. Quelqu’un récolte les besoins, fait relire la synthèse (dans le meilleur des cas) et un beau document est transmis à l’équipe de développement.

Sauf qu’avec un cahier des charges, pas moyen de faire machine arrière. Comme quand vous commandez une pizza sur internet : une fois qu’elle est partie, impossible de changer d’avis ! S’il manque les olives, vous survivrez… Si par contre de nouveaux besoins apparaissent alors que votre cahier des charges est figé, tout devient compliqué

Dans la méthode lean startup que nous appliquons, notre objectif principal est de tester des hypothèses. Pour savoir ce que veulent vraiment les utilisateurs. Pour chaque fonctionnalité, trois étapes : 1/ idée 2/ implémentation 3/ test. Si cela fonctionne, nous gardons. Si cela ne fonctionne pas, nous modifions ou nous supprimons. À chaque cycle, nous enrichissons nos connaissances. Nos hypothèses deviennent de plus en plus éclairées.

Grâce à cela, nous sommes capables de naviguer dans l’incertitude. D’embrasser le changement. De nous rapprocher tangentiellement des besoins de nos utilisateurs. C’est comme cela que fonctionne la vie : impossible à capturer, toujours sur le vif. Nous essayons seulement de l’imiter. Parce qu’il est impossible d’atteindre une cible mouvante avec un système sclérosé.

De quel côté sont les algorithmes de recommandation ?

Nous sommes en 2018, à Paris. Je suis dans une voiture, sur le périphérique. Je vois une publicité de dix mètres de haut pour la sortie du nouvel album d’un groupe de musique (The Blaze). Soudain, je me sens trahi et je passe le reste du trajet à me poser cette question  : de quel côté sont les algorithmes de recommandation ?

Petit retour en arrière. Depuis plusieurs années, j’écoute de la musique sur Spotify. Ma fonctionnalité préférée : « Découvertes de la semaine ». Chaque semaine, un algorithme de recommandation me suggère de nouvelles chansons, en fonction de ce que j’écoute habituellement. Je me sens spécial. Je me sens compris. J’ai un algorithme qui sélectionne rien que pour moi des titres qui pourraient me plaire.

Il y a quelques semaines, un nouveau groupe a fait son apparition dans cette sélection : The Blaze. Effectivement, leur son me plait. C’est original. Ils n’ont pas l’air très connus. J’ai l’impression que l’algorithme de recommandation m’a fait découvrir une pépite qui était bien cachée.

Voilà pourquoi l’apparition de cette publicité géante sur le périphérique est une telle claque pour moi. Parce qu’elle me fait me poser la question suivante : est-ce que l’algorithme de Spotify m’a recommandé cette musique parce qu’elle pouvait me plaire, ou bien parce que quelqu’un a payé pour cela ? Peut-être est-ce même un mélange des deux… Je viens de me rendre compte que je ne connais finalement rien de l’objectif de l’algorithme.

Si nous voulons développer la confiance envers les algorithmes, la première étape serait de rendre transparents les objectifs visés par ces derniers. Cela peut se faire sans dévoiler le fonctionnement de l’algorithme. Simplement en partageant la fonction objectif que l’algorithme de recommandation tente d’optimiser. C’est le premier pas à faire pour que les objectifs des algorithmes se réalignent avec les objectifs de l’humanité. Afin qu’à la question « de quel côté sont les algorithmes de recommandation ? », la réponse soit évidente : du nôtre.

Refactoriser l’administration

Dans le milieu du développement logiciel, il existe une bonne pratique qui s’appelle « refactoriser ». Refactoriser implique de reprendre le code déjà écrit. Pas pour ajouter de nouvelles fonctionnalités. Plutôt pour rendre le code plus clair, plus lisible et plus maintenable. Enlever le superflu. Supprimer les doublons. Ré-écrire le code source afin que le logiciel produise les mêmes résultats, mais de manière à ce qu’il fonctionne sur le long terme et intégré dans un système complexe.

Refactoriser n’est pas la spécialité de l’administration. Quand un nouveau problème surgit, souvent une nouvelle structure est créée. Et si plus tard le même problème réapparaît, le premier réflexe sera de créer encore une nouvelle entité pour le résoudre. Sans modifier l’ancienne. Sans la supprimer. En laissant des couches et des couches de structures sédimenter les unes sur les autres. Ce qui génère généralement de nouveaux problèmes…

En développement, cela s’appelle le « code spaghetti ». Des morceaux qui partent dans tous les sens, indémêlables, adhérents les uns aux autres. Quand les développeurs rencontrent du code spaghetti, ils n’ont qu’une envie : tout jeter à la poubelle afin de repartir de zéro.

Je préférerais que l’administration ne finisse pas un jour par être jeter toute entière à la poubelle afin de repartir de zéro. Pour limiter les chances que cela arrive, passer du temps à la refactoriser me semble important. Au lieu de créer systématiquement de nouvelles structures, essayer de transformer en profondeur celles qui existent. Enlever le superflu. Supprimer les doublons. Ré-écrire nos directives afin que l’administration produise les mêmes résultats, mais de manière à ce qu’elle fonctionne sur le long terme et intégrée dans un système complexe.

L'humilité comme réponse au complotisme

En occultant systématiquement le doute, en cachant la nuance, en déclarant catégoriquement que ceci est vrai, on crée la théorie du complot par réaction naturelle: tôt ou tard le doute ou l’erreur réapparaîtront, et les complotistes auront leurs «preuves» d’un mensonge. •8/51

Cet extrait du fil Twitter du mathématicien David Madore résume sa réflexion par rapport aux origines du complotisme. Au lieu d’évoquer les algorithmes de recommandation et leur penchant pour le sensationnalisme, David estime que la responsabilité incombe au manque de nuance des discours politiques.

Pourquoi ? Parce que le monde est complexe et imprévisible. Lisez Nassim Nicholas Taleb si vous avez encore des doutes. Par conséquent, quand on ne nous présente que des certitudes, notre détecteur à bullshit s’active et nous prévient que quelque chose ne va pas. Certains tentent alors de trouver des réponses « alternatives » à leurs questions et finissent absorbés par les théories du complot.

Pour construire de la confiance, nous avons paradoxalement besoin d’humilité. De récits d’échec. De partage des moments de doute. Parce que l’humanité ne progresse que d’une seule manière : essai, erreur, changement. C’est comme cela que nous apprenons à marcher ou à parler. C’est comme cela que la science avance. Essai, erreur, changement.

Dans chaque épisode de Hackers publics, je demande à mes invités de présenter leur plus gros échec. C’est important de montrer que nous nous trompons tous et que, généralement, ce n’est pas grave^*. Nous devons cultiver l’humilité, dont manque souvent les grosses structures comme l’administration. Parce que la seule certitude, c’est que tout change constamment.

–

^* une erreur peut être grave quand il y a un risque de ruine, au sens de la théorie de jeux, c’est-à-dire une situation dont nous ne pouvons pas nous remettre, comme la mort.

On commence demain

Aujourd’hui, nous avons rendu deux personnes heureuses dans l’administration avec cette simple réponse : « on commence demain ! ».

Ce matin, un intrapreneur potentiel nous contacte pour nous présenter son idée. Elle remplit tous nos critères de sélection. Nous proposons au porteur de commencer dès demain une investigation pour aller creuser le potentiel de cette idée. Il nous avoue qu’il n’est pas habitué à ce genre de réponse. Il craignait en plus que son idée ne soit pas assez innovante.

Ce soir, des agents d’un autre ministère nous appellent. Ils veulent réutiliser un de nos produits. Ils connaissent déjà les rouages des projets interministériels et nous demandent quand nous pourrions leur fournir une instance de test pour faire valider en interne que notre outil répond bien à leur besoin. Envoyez-nous le mail de la personne qui sera le super admin, nous vous ouvrons une nouvelle instance dès demain. Ils n’en revenaient pas.

Passer par un incubateur ministériel n’est pas la panacée. Pour des petits projets, pour des logiciels dont les spécifications sont déjà écrites, quand il n’y pas d’incertitude, mieux vaut trouver un autre partenaire.

Mais s’il faut faire vite et bien (car la rapidité et la qualité vont de paire dans le monde logiciel), nous sommes là. Grâce au devops, à nos équipes interdisciplinaires, à notre indépendance (qui nous confère une grande responsabilité), nous sommes capables d’être au rendez-vous plus vite que quiconque.

On commence demain ?

Les faits et les croyances

Même si les faits prouvent le contraire, il est toujours long et difficile de changer les croyances.

Au XIX^ème siècle, un docteur hongrois du nom de Semmelweis, a compris et prouvé empiriquement que le lavage des mains diminuait fortement les infections dans les maternités. À l’époque, les étudiants en médecine réalisaient des accouchements après des autopsies, sans se laver les mains, ramenant avec eux tout un tas de germes. Il y avait de 10 % à 40 % de mortalité dans ces maternités.

Mais se laver les mains n’était pas dans les habitudes. On n’y croyait pas. Personne ne voulait se remettre en question.

De nos jours, des équipes de chercheurs aux États-Unis, en Angleterre et ailleurs relancent des études sur l’utilisation des psychédéliques (LSD, psilocybine, …) pour soigner des maladies comme la dépression ou le syndrome de stress post-traumatique. Les premiers résultats sont très prometteurs mais ces substances ont été tellement dénigrées pendant des décennies qu’il va falloir attendre encore longtemps avant qu’elles puissent être autorisées en France dans un cadre thérapeutique.

On n’y croit pas. Pas encore en tout cas.

Semmelweis n’était pas un bon communiquant. Il n’a pas réussi de son vivant à changer les croyances, malgré ses preuves. Mais grâce à son travail de pionnier, le lavage des mains est devenu une norme d’hygiène élémentaire.

Les croyances changent difficilement. Il faut de la persévérance pour continuer, jour après jour, à transformer une culture. Mais le jeu en vaut la chandelle car une fois que les croyances ont changé, c’est pour de bon.

Résumé du livre « Accelerate » (1/n)

Parce que certaines idées méritent d’être diffusées, je teste un nouveau format d’article : le résumé de livre.

Pour ce premier résumé, j’ai choisi Accelerate: Building and Scaling High-Performing Technology Organizations que l’on m’a plusieurs fois conseillé. L’idée principale de ce livre est que les organisations ont intérêt à accélérer la livraison de leurs produits numériques car cela améliore leur performance à tous les niveaux. Cette accélération est accompagnée d’une amélioration de la qualité, rendue possible par des changements organisationnels et méthodologiques, regroupés sous le terme DevOps.

Dans cette première partie, vous apprendrez comment mesurer la performance de production de logiciel et quelle est la culture des équipes les plus performantes. Bonne lecture !

Chapitre 1 - accélérer

Aujourd’hui, tous les secteurs ont tendance à accélérer. Cette accélération est principalement dûe au développement logiciel, qui évolue grâce à des nouvelles pratiques comme le mouvement DevOps. Le DevOps est né pour répondre à cette question : comment construire des systèmes sûrs, résilients, évolutifs et distribués, à grande échelle ?

Certaines organisations pratiquent ces méthodes de développement modernes mais beaucoup ne se sont pas ou peu transformées. Une telle transformation nécessite de se concentrer sur ses capacités (i.e. « comment j’améliore mes résultats clés grâce à mes capacités ? ») plutôt que sur sa maturité (i.e. « où j’en suis dans ma transformation ? »). Une organisation ne peut jamais se considérer comme mature : l’environnement change continuellement et livrer rapidement des logiciels fiables est une quête perpétuelle.

La question qui se pose alors est : sur quelles capacités se concentrer ? À travers leurs recherches, les auteurs en ont identifié vingt-quatre, qui seront détaillées dans les chapitres suivants.

Chapitre 2 - mesurer la performance

Avant toute chose, il faut définir ce qu’est la performance pour une équipe qui produit des logiciels. Les méthodes classiques de mesure de cette performance ont deux problèmes : elles se concentrent sur la production (output) plutôt que sur le résultat (outcome), et sur des mesures individuelles plutôt qu’en équipe. Pour éviter ces écueils, il faut donc chercher des indicateurs qui se concentrent sur le résultat, et mesurés de manière collective.

Les auteurs ont sélectionnés quatre indicateurs qui possèdent ces caractéristiques :

• Le délai de livraison (delivery lead time) : le temps qu’il faut pour passer du code archivé (committed) au code mis en production avec succès ;
• La fréquence de déploiement : la fréquence à laquelle le code est déployé en production ou dans un magasin d’applications ;
• Le délai de restauration moyen : le temps moyen nécessaire pour restaurer le service suite à un incident ;
• Le taux d’échec de changement : le pourcentage de changement de code qui entraîne une dégradation du service ou exige une réparation comme un retour en arrière (rollback).

Pour récolter leurs données, les auteurs ont organisé un sondage annuel de 2014 à 2017 pour savoir comment les organisations se situaient par rapport à ces quatre indicateurs. Ils ont ensuite réalisé une analyse par partitionnement (cluster analysis) pour séparer les organisations en trois groupes en fonction de leur performance : bonne, moyenne et mauvaise.

Un point intéressant : les organisations qui sont performantes sont bonnes sur les quatre indicateurs. Il n’y a donc pas de compromis entre qualité et rapidité ; plus on va vite, plus on fait du bon code. À noter que l’écart de performance entre les organisations se creuse d’année en année.

La performance en livraison logicielle est très importante car elle prédit (au sens statistique) la performance commerciale des entreprises et de la performance non-commerciale des autres organisations.

Comment faire alors pour améliorer la performance en livraison logicielle ? Certes, il faut des outils adaptés, mais il est d’abord indispensable d’avoir la bonne culture organisationnelle.

Chapitre 3 - mesurer et changer la culture

Le sociologue Ron Westrum a développé une typologie pour classer les cultures organisationnelles :

• Pathologique (axé sur le pouvoir) : l’organisation est basée sur la peur et les menaces. Les individus font de la rétention d’informations.
• Bureaucratique (axé sur les règles) : l’organisation protège les départements. Ces départements défendent leur pré carré et agissent selon leurs propres règles.
• Générative (axé sur la performance) : l’organisation se concentre sur sa mission. Tout est subordonné à la performance et à la raison d’être.

Afin d’estimer où se positionnaient les différentes organisations dans ce continuum culturel, les auteurs ont posé des questions pour savoir notamment si les responsabilités étaient partagées, si le travail inter-équipe était encouragé et si les échecs entraînaient une enquête pour améliorer les processus plutôt que pour désigner un coupable.

Les résultats de l’étude montrent que la culture organisationnelle prédit la performance en livraison logicielle et la performance commerciale : plus une organisation est générative (et donc plus les informations circulent de manière fluide), plus elle est performante.

Un point à souligner : la culture organisationnelle n’est pas liée au type d’organisation. Il existe des organisations gouvernementales génératives et des startups pathologiques.

La bonne nouvelle, c’est que pour avoir une culture plus générative, il ne faut pas changer les personnes, mais la manière dont elles agissent et leurs interactions au sein des équipes (voir l’étude de Google en 2015 sur le sujet ou l’article de John Shook sur la transformation d’un site de production automobile). Les concepts de management lean et de livraison continue, qui seront développés dans les chapitres suivants, prédisent en effet la culture organisationnelle.

Dans la prochaine partie de ce résumé, vous découvrirez quelles sont les pratiques techniques qui permettent de transformer la culture et d’améliorer la performance de livraison logicielle. À très vite !

Trois améliorations pour l'accompagnement des startups d'État

Pour lancer une startup d’État dans notre incubateur, trois ingrédients sont indispensables :

1. un intrapreneur investi ;
2. un problème identifié ;
3. une équipe autonome.

Cela fonctionne : nous avons lancé plusieurs services numériques avec succès. Mais rien n’est jamais parfait et voici quelques-uns des aspects que nous pourrions améliorer :

1/ Il faudrait mieux récompenser les intrapreneurs.

La seule récompense offerte à nos intrapreneurs, c’est la fierté d’avoir développer un nouveau produit ayant un impact. Pourtant, ils prennent des risques. Ils sont responsables de leur produit. Ils mettent leur peau en jeu. Leur récompense devrait être proportionnelle à leur prise de risque. Pourquoi ne pas créer par exemple une prime liée à l’objectif de la startup d’État ? Avec le risque d’attirer des intrapreneurs pour de mauvaises raisons…

2/ Il faudrait préincuber tous les produits.

Lancer une startup d’État est un engagement important : six mois et 200 000 €. Pour limiter les risques, nous expérimentons un programme de préincubation. Durant deux mois, nous nous assurons qu’il existe bien un problème identifié et que ce problème peut être résolu par un produit numérique. Cette « période d’essai » permet également de nous assurer que l’intrapreneur est investi, sans engager trop de dépenses. Avec le risque de ralentir le développement des produits…

3/ Il faudrait formaliser l’autonomie des équipes.

Même si nous privilégions la collaboration à la négociation contractuelle, certaines modalités de fonctionnement des startups d’État mériteraient d’être plus cadrées. C’est d’autant plus important que l’incubateur grandit rapidement. L’autonomie des équipes est un de ces aspects cruciaux. En effet, lorsque les startups d’État prennent de l’ampleur, de plus en plus d’acteurs s’y intéressent et veulent s’impliquer dans la prise de décision. Quand cela arrive, il devient plus difficile de rester à l’écoute des utilisateurs et de faire du vrai design. Un papier officialisant l’autonomie de l’équipe pourrait aider. Avec le risque qu’un papier ait peu de poids face aux rapports hiérarchiques…

Valorisation des intrapreneurs, préincubation des startups d’État et formalisation de l’autonomie des équipes : voilà de quoi nous occuper pour les mois à venir !

Trois conditions pour lancer une startup d'État

Après un an et demi à lancer de nouveaux services numériques dans l’administration, nous avons beaucoup appris. À force de voir les mêmes problèmes surgir, nous imposons par exemple désormais trois conditions à chaque nouvelle startup d’État. Respecter ces conditions ne garantit pas le succès, mais passer outre entraine souvent un échec. Voici ces trois conditions :

1/ Il faut un intrapreneur qui consacre au moins 20 % de son temps à la startup d’État.

Cela peut paraître étonnant, mais c’est souvent le point le plus bloquant. Il est en effet facile d’avoir une bonne idée, mais la concrétiser est un travail difficile. Dans les startups d’État, il faut trouver ses premiers utilisateurs en moins de six mois. Il faut donc un intrapreneur disponible, impliqué, qui connaisse son métier et qui veuille vraiment résoudre un irritant. Les projets où il n’y à pas de porteur clairement identifié, ou bien un porteur « désigné volontaire » ont tendance à patauger et à nous épuiser.

2/ Il faut un problème identifié plutôt qu’un cahier des charges.

La méthode que nous appliquons excelle dans l’incertitude. Cette méthode se base sur des cycles itératifs courts de construction/mesure/apprentissage. L’incertitude, c’est quand il existe un problème qu’on ne sait pas exactement comment résoudre, même si l’on a quelques intuitions sur le sujet. Les incubateurs de services numériques ne sont donc pas le bon endroit pour les projets arrivant avec un cahier des charges bien défini. Pour ces derniers, les entreprises titulaires de marchés publics sont heureusement prêtes à délester l’administration de quelques millions d’euros.

3/ Il faut un sponsor de haut niveau qui accorde de l’autonomie à l’équipe.

Si chaque décision doit être validée par un comité de pilotage, il est impossible de sortir un produit en moins de six mois. Une startup d’État doit être autonome. Autonome ne signifie pas que personne ne rend compte. Cela veut seulement dire que l’équipe a une mission claire sur laquelle elle est jugée, mais qu’elle a le droit de prendre seule des décisions lui permettant d’atteindre ses objectifs. Il faut donc une personne suffisamment haut placée dans l’administration pour accorder sa confiance à l’équipe et la protéger des lourdeurs bureaucratiques.

Ces trois conditions ont le mérite d’être simples et faciles à vérifier. Il en existe sûrement beaucoup d’autres que nous n’avons pas identifiées ou qui s’applique à d’autres contextes. N’hésitez pas à me partager les vôtres sur Twitter (@seiteta) ou par courriel (blog@f14e.fr) !

Se lire et se voir en télétravail

À la Fabrique numérique, 80 % des équipes travaillaient déjà à distance avant le confinement donc assez peu de choses ont changé pour nous.

Nous avons quand même modifié deux de nos habitudes : le point de synchronisation hebdomadaire et les rencontres informelles.

Le point de synchronisation hebdomadaire est le rendez-vous durant lequel nous partageons les avancées et les points de blocage de nos produits. Au lieu d’une réunion en visioconférence où chaque équipe parlait pendant quelques minutes, nous faisons maintenant cela par écrit, dans notre application de messagerie instantanée. Un fil de discussion par produit, tout le monde écrit en même temps et pose ensuite des questions.

Avantages :

• Il y a plus de personnes qui interviennent ;
• Cette solution passe mieux à l’échelle ;
• Nous avons une trace de ce qui s’est passé chaque semaine.

Inconvénient :

• Le partage d’information est moins bon car tout le monde ne lit pas forcément tous les fils de discussion.

Les rencontres informelles ont lieu moins spontanément quand tout le monde est à distance, surtout pour les 20 % qui avaient l’habitude de travailler physiquement au même endroit. Nous organisons donc des rendez-vous virtuels, en début et en fin de journée, pour discuter de tout et de rien. La présence est facultative et les discussions sont libres, comme dans la vraie vie.

Avantages :

• Des nouveaux liens se font entre des gens qui ne se connaissaient pas ;
• Cela offre un aperçu d’une autre facette de la vie de ses collègues.

Inconvénient :

• Il faut s’habiller pour aller télé-travailler.

–

Prenez soin de vous.

Ne pas tomber amoureux de ses idées

C’est un risque pour toutes celles et ceux qui travaillent plus avec leur cerveau qu’avec leur corps : tomber amoureux de ses idées.

Est-ce de l’ego ? Est-ce de l’attachement ? En tout cas, nous y sommes tous confrontés : cette nouvelle fonctionnalité, ce nouveau service que j’ai imaginé est génial et les gens qui critiquent mon idée m’attaquent personnellement.

Sauf que nous ne sommes pas nos idées. Nous sommes ce que nous faisons.

Les designers ayant travaillé dans des agences où ils ont dû reprendre leurs œuvres des centaines de fois face à des clients girouettes, savent que tout n’est qu’un éternel recommencement. Ils ont appris le lâcher-prise.

Mais comment ne pas s’accrocher à ses idées lorsque nous n’avons pas de clients ?

La première étape est de tester ses idées, de les faire affronter le monde réel. Même si la théorie est parfois séduisante, la pratique est la seule chose qui permet d’avoir une influence sur le monde.

La seconde étape est de se rattacher à des objectifs. Nos idées n’existent pas pour elles-mêmes, mais pour nous permettre de réaliser quelque chose. Et heureusement, il existe beaucoup de chemins pour arriver à chaque destination.

Enfin, il faut se rappeler sans cesse que le seul moyen d’avoir une bonne idée, c’est d’en avoir déjà plein de mauvaises.

Grossir ou se reproduire ?

Pourquoi est-ce que les êtres humains ne mesurent pas 20 mètres ?

Parce qu’après une vingtaine d’années de croissance, nous arrêtons de grandir. Notre taille est à la fois adaptée à notre environnement, et contrainte par les lois physiques qui régissent l’univers.

Pour continuer de se propager, nos gènes préfèrent créer un ou plusieurs nouveaux spécimens, plutôt que de nous faire grandir indéfiniment. Et pour s’assurer que les nouveaux venus survivent, nous (et le reste de la société) leur apprenons ce que nous savons.

Après avoir dépassé une certaine taille, peut-être que les structures feraient mieux d’arrêter de croître également. Une trop grande taille engendre des problèmes de communication et rend plus difficile de s’adapter aux modifications incessantes qui sont devenus la norme.

Pour continuer de grandir, une solution est de se répliquer, en partageant sa manière de faire, plutôt que de devenir trop grand. Et pour s’assurer que les nouvelles structures ainsi créées survivent, il est nécessaire de les former et de leur partager tout le savoir acquis.

Il n’existe pas un unique restaurant McDonald’s de la taille d’une ville, mais plutôt des dizaines de milliers de restaurants franchisés capables de servir 69 millions de clients par jour. Il n’y a pas non plus une seule conférence TED gigantesque, mais à la place un système de licence qui a permis d’organiser plus de 32000 conférences TEDx dans le monde entier.

L’incubateur de services numériques de la DINUM a emprunté une voie similaire en encourageant l’émergence d’incubateurs ministériels mis en réseau. L’association Data for Good favorise aussi l’émergence de chapitres régionaux indépendants pour continuer à réaliser plus de projets tout en restant à taille humaine.

Pour bénéficier pleinement de la multitude, pourquoi ne pas choisir la réplication et la formation, à la place de la croissance infinie d’une entité centralisée ?

Les secrets d'une documentation interne réussie

Dans toutes les structures, il existe un ensemble de règles qui détermine ce que nous pouvons faire et comment nous devons le faire.

Dans les structures bureaucratiques ces règles sont très précises et consignées dans divers documents (instructions, directives, règlements,…).

Le problème est que plus personne ne semble capable de les changer, comme si elles avaient une existence propre. Des règles absurdes ou contradictoires finissent par s’accumuler. Les informations sont fragmentées et il devient difficile de savoir quelle est la règle en vigueur sur un sujet donné.

Dans les petites structures agiles, les règles sont généralement transmises à l’oral, faute de temps sans doute, par crainte de se transformer en bureaucratie peut-être. Des règles existent mais elles ne sont pas documentées. Tout le monde sait par exemple qu’il faut envoyer les justificatifs de ses notes de frais à Georges, même si cela n’est écrit nul part.

Cependant le passage à l’échelle est compliqué. S’il est facile de partager les informations oralement à dix, les problèmes arrivent une fois que les structures comptent plusieurs centaines de personnes ou doublent de taille chaque mois. Et lorsque les règles ne sont pas écrites, comment les changer ?

Il est pourtant possible de créer un système qui rassemble le meilleur des deux mondes en respectant deux impératifs :

1/ Les règles doivent être facilement accessibles. Cela implique que la documentation soit centralisée, explorable via un moteur de recherche et une arborescence bien pensée, et surtout toujours à jour ;

2/ Les règles doivent être facilement modifiables. N’importe qui doit pouvoir proposer un changement dans les règles et un mécanisme clair doit exister pour valider des changements.

Le handbook de l’entreprise Gitlab est une très bon exemple de documentation interne qui respecte ces principes.

Accessibilité et mutabilité : voici les secrets d’un système de documentation efficace et robuste.

Who are the maddest?

La série Mad Men tourne autour d’une agence de publicité new-yorkaise dans les années 60. Régulièrement ont lieu des scènes assez ressemblantes à ce que nous pouvons vivre de nos jours dans l’informatique. Pardon, le numérique.

La scène se déroule ainsi :

• Un des clients de l’agence arrive avec une idée préconçue sur ses propres clients, ou avec une campagne très précise en tête ;

• Les Mad Men lui montre que ses aprioris ne sont pas vérifiés, soit en par une démonstration scientifique, soit en effectuant des tests sur de petits groupes (entre deux verres de whisky et une trentaine de clopes) ;

• Le client sort mécontent car il voulait seulement faire valider son opinion par des pros. Ou en version happy end : le directeur créatif, Don, arrive à les convaincre qu’il vaut mieux laisser les professionnels faire leur travail.

Nous nous retrouvons parfois dans des situations similaires au sein de notre incubateur. Les porteurs de projet viennent nous voir avec leurs idées en tête. Et nous leur expliquons que notre méthode consiste notamment à discuter avec les utilisateurs finaux (aka les vrais gens).

Sauf que pour certains, parler aux utilisateurs ne devrait servir qu’à valider les hypothèses qu’ils ont déjà émis. Autant rester dans notre bureau dans ce cas…

Les vrais intrapreneurs, celles et ceux avec qui nous construisons les meilleurs produits, ne partagent pas cet état d’esprit. Ils arrivent avec un problème et cherche à construire la meilleure solution possible avec les utilisateurs.

Cela semble être seulement du bon sens. Mais le bon sens est rarement la seule force à l’œuvre quand nous cherchons à résoudre les problèmes des autres.

Au secours, un algorithme gère la cantine !

La nouvelle est tombée à la rentrée : c’est désormais un algorithme qui choisit les menus de la cantine de vos enfants.

Les premières semaines tout se passe bien : l’algorithme teste tous les plats possibles et pèse le poids des plateaux à la sortie, afin de s’assurer que les enfants finissent bien leur assiette.

Au bout de quelques mois, l’algorithme obtient un score presque parfait car la plupart des plateaux sont vides à la fin du repas. Sauf que vos enfants ne mangent plus que des burgers, des frites, des glaces et des pizzas…

Les algorithmes de recommandation des plateformes numériques fonctionnent de manière similaire. À force de vouloir nous faire rester le plus longtemps possible (pour nous montrer des publicités), ils finissent par ne nous proposer que les vidéos les plus addictives.

S’assurer que des plateaux sont vides ou que nous restons longtemps sur un site est facile à mesurer. Mais il faut toujours se méfier de ce qui est facile à mesurer. Est-ce vraiment ce qu’il faut tenter d’optimiser ?

L’objectif de l’algorithme de notre cantine devrait être que nos enfants soient en bonne santé, même si cela est plus difficile à mesurer que le poids des plateaux.

Et de la même manière, nous pourrions attendre des plateformes numériques que les objectifs de leurs algorithmes soient plus alignés avec ce que nous voulons dans notre société et dans nos vies : apprendre, rire, s’amuser, aimer… Plutôt que passer la nuit devant un écran.

Des habitudes émergentes

Depuis la grève des transports, le nombre de vélos roulants chaque jour à Paris a été multiplié par 3. Aucun cycliste n’a l’habitude de rouler avec autant de comparses. C’est donc un joyeux bordel sur les pistes cyclables car personne ne sait vraiment comment agir dans ce genre de situation.

Dans les systèmes bien établis, comme la circulation automobile, des règles spontanées se mettent en place au fur et à mesure. Quand le périphérique est bouché, l’usage est qu’une voiture sur deux cède le passage à l’entrée des bretelles pour fluidifier le trafic.

Ce comportement n’est pas inscrit dans le code de la route mais a émergé jusqu’à devenir une règle implicite respectée par la plupart.

Dans le cas des vélos, l’augmentation du nombre de cyclistes a été si brutale que ces comportements émergents n’ont pas eu le temps d’apparaître.

Qu’est-ce cela implique pour nous dans le contexte de l’innovation publique ?

1/ Certaines habitudes sont extrêmement difficiles à changer car elles ont émergées spontanément et sont implicites. Comment modifier une loi qui n’est écrite nulle part ?

2/ Lors de changements rapides, il y a toujours une période d’adaptation un peu chaotique car ces comportements émergents n’ont pas encore eu le temps de se former. Comment prévoir des comportements qui émergent au sein d’un groupe, parfois sans que les individus en soient conscients ?

Une seule certitude : le changement prend toujours du temps.

–

En parlant de changement, le rythme de publication de f14e.fr évolue et passe à un article par semaine (au lieu d’un article par jour pendant une semaine puis plus rien la semaine suivante 😁 ).

Répare-le toi-même !

Sur les réseaux sociaux, on croise régulièrement des développeurs qui râlent à propos de logiciels open source qui ne marchent pas bien ou auxquels il manque des fonctionnalités.

La réponse de celles et ceux qui ont créé ces briques ouvertes est souvent cinglante : « Tout cela a été créé sur notre temps libre. Déjà, dis merci. Ensuite, si cela ne te plaît pas, le code est ouvert donc répare-le toi-même ! ».

C’est également un classique des grandes organisations : toutes ces personnes qui vous disent ce que vous devriez faire et comment, sans que vous n’ayez demandé quoique ce soit.

Et c’est normal dans les organisations qui fonctionnent en silo et dans lesquels chaque individu n’est responsable que d’un tout petit périmètre. Comment faire autrement que de demander aux autres de faire pour nous ?

Sauf que l’époque est à l’ouverture et à l’horizontalité. Et dans ce type d’organisation, la seule réponse que nous pouvons donner quand on nous dit ce qui devrait être fait est : « Tu viens m’aider à le faire ? ».

–

Ajout de dernière minute : alors que je m’apprêtais à publier l’article, Antoine, qui en avait marre que les marges de mon blog soient trop fines sur mobile, a fait la modification lui-même. Merci Antoine !

Qualité : startups vs administration

Je viens de recevoir la carte de tiers payant de ma mutuelle en ligne. L’emballage est parfait, le design de la carte, très sympa. En bonus : des autocollants de super qualité et l’information que je suis désormais remboursé si je m’abonne à une application de méditation.

Pour certains, ce ne sont que des détails. Ce qui compte dans une mutuelle, c’est la manière dont elle nous rembourse, non ? Sauf qu’ici, l’attention aux détails de ma mutuelle est la même que ce soit pour les remboursements ou l’envoi d’une simple carte. Et tout est parfait.

Tout ça ne s’est pas fait tout seul. J’imagine le travail nécessaire pour arriver à cette qualité d’exécution.

Est-ce qu’il existe une seule procédure administrative qui soit aussi bien réalisée ? Pas à ma connaissance.

Pourtant, ce n’est pas une question d’échelle. Beaucoup de procédures administratives ont beaucoup moins d’utilisateurs que ma mutuelle.

Ce n’est pas une question d’argent non plus. Le prix de la mutuelle est équivalent (voire inférieur) à celui d’autres mutuelles qui proposent des expériences client dégueulasses.

Deux choses manquent aux administrations pour arriver à un tel niveau de qualité :

1/ la culture produit, qui se concentre sur ce dont ont vraiment besoin les usagers, plutôt que ce dont a besoin l’administration.

2/ la culture design, qui propose de s’attarder sur tous les détails qui font un produit, afin que nous éprouvions une émotion particulière en l’utilisant.

Pour créer des services publics numériques aussi bien réalisés, nous devons donc continuer à recruter des product managers et des designers qui vont faire infuser ces nouvelles cultures.

Tout cela pour qu’un jour, ce soit les startups qui se demandent comment les administrations font pour réaliser des services et des produits aussi parfaits.

Pourquoi je lance un podcast sur l'innovation publique en 2020

Le matériel est prêt, la première interview est calée : c’est bon, je lance à la rentrée un podcast pour aller à la rencontre de celles et ceux qui innovent et participent à la transformation de l’administration.

Le podcast est un bon format pour parler de ce genre de sujet complexe car il permet de prendre le temps de creuser, de détailler, d’expliquer.

À travers ce podcast, je vais tenter de remplir trois objectifs :

1/ Montrer que vous n’êtes pas seul. La communauté de celles et ceux qui transforme l’administration grandit sans cesse. Elle est en train d’atteindre une taille critique qui va lui permettre de résoudre de nouveaux défis. Je vais interviewer les personnes qui composent cette communauté si diverse.

2/ Fournir de l’inspiration. Vous lancez un incubateur public ? Vous créez un service public numérique ? Vous voulez rendre votre organisation plus horizontale ? Venez écouter celles et ceux qui ont déjà dû affronter ce qui vous attend.

3/ Donner envie de nous rejoindre. Vous n’êtes pas dans la fonction publique mais vous sentez qu’il se passe un truc important en ce moment ? Vous voulez travailler pour l’intérêt général mais en restant à la pointe de ce qui se fait dans la tech ? Découvrez les entrepreneurs publics avec qui vous adoreriez travailler !

Vous l’aurez compris, j’ai vraiment hâte de lancer ce nouveau projet et de vous faire écouter ça. Si vous voulez être sûr de ne pas manquer le lancement, vous pouvez vous abonner à ce blog par courriel ou via le flux RSS, ou encore me suivre sur Twitter.

Les projets cache-misères

Dans mon ancien appartement, tout le couloir était recouvert de lambris. Quelle est la fonction principale du lambris ? Cacher la misère. Plutôt que de traiter les problèmes d’infiltration et de refaire les murs, ceux qui ont fait les travaux ont préféré tout camoufler. Résultat : tout l’appartement était à refaire au bout de quelques années.

N’est-ce pas un phénomène que nous rencontrons fréquemment dans les grandes structures ? Au lieu de nous attaquer aux problèmes de fond, il est plus facile de mettre des pansements sur une jambe de bois.

Pourquoi par exemple lancer une « marque employeur » alors que nous ne sommes parfois même pas capables de rendre son poste à une femme qui rentre de congé maternité ? (pas dans mon administration, mais histoire vraie)

L’excuse est souvent la même : « ce n’est pas mon sujet… ». La malédiction des grandes organisations, c’est que tout est séparé en tellement de petits morceaux que personne n’est plus responsable de rien. Il est donc très compliqué de mettre autre chose que des pansements.

La solution existe pourtant : créer des équipes dédiées et interdisciplinaires qui travaillent sur un problème clairement identifié. Parce que pour faire une belle pièce qui sera agréable à vivre pendant longtemps, il faut parfois tout péter et tout refaire. Plutôt que de mettre du lambris.

Accepter d'arrêter

Vous travaillez sur un projet depuis un an. C’est un peu votre bébé. Vous avez dépensé des milliers d’euros et passé des centaines d’heures en réunion pour le lancer. Le projet sort. Personne ne l’utilise. Vous l’améliorez. Toujours personne. Êtes-vous prêt à tout stopper ? À expliquer à vos chefs qu’il vaut mieux arrêter ?

En tant qu’humain nous détestons les coûts irrécupérables (sunk cost) : quand nous (nous) investissons dans quelque chose, financièrement ou sentimentalement, nous préférons continuer d’investir plutôt que d’admettre qu’il serait parfois plus sage d’arrêter.

Est-ce programmé dans nos cerveaux à cause de l’évolution ou est-ce le fruit de notre culture ? Aucune idée. Mais ce que je sais, c’est qu’il est plus facile de lancer un projet que de le tuer.

Quelles implications pour l’innovation publique ?

1/ D’un point de vue structurel, il faut créer des moments où nous pouvons nous poser et regarder si la meilleure chose à faire ne serait pas d’arrêter. Le mode de financement des startups d’État est intéressant à cet égard : tous les six mois, il faut redemander un financement et donc choisir si nous poursuivons ou pas.

2/ D’un point de vue culturel, il faut rappeler encore et toujours que ce n’est pas grave. Oui il s’agit d’argent public, et nous préférerions ne pas nous être trompé. Mais n’est-il pas mieux d’avoir dépensé un peu d’argent public et appris une leçon que nous partagerons, que d’en dépenser beaucoup pour un échec cuisant que nous essaierons de camoufler ? Quel est le meilleur chemin vers le progrès ?

3/ D’un point de vue produit, c’est la raison pour laquelle nous n’attendons pas que sorte le « super projet qui fera tout d’ici quelques années », même s’il cela crée de la redondance. Car combien de gros projets n’existent encore seulement parce que personne n’a eu le courage de les arrêter ?

Pour nous en sortir, la question que nous devons nous poser est la suivante : si un inconnu me donnait ce projet, gratuitement, est-ce que je l’accepterais ? Si la réponse est non, vous savez ce qu’il vous reste à faire.

L’administration ou les usagers ?

Le premier point du manifeste du réseau des incubateurs publics beta.gouv.fr est limpide :

Considérer les besoins des usagers avant ceux de l’administration

Facile à dire. Plus compliqué à mettre en œuvre.

En effet : qui paye les projets ? Qui prend les décisions ? L’administration (ou plutôt ses dirigeants). Pas les usagers.

À première vue, nous pourrions croire que les deux visions peuvent s’accorder et que nous pouvons satisfaire les chefs et les utilisateurs. Or les objectifs sont parfois éloignés.

Sur un site web par exemple, l’administration veut pousser le plus d’informations possible. Alors que l’usager cherche seulement une réponse facilement accessible à ses questions.

Comment faire alors ?

Trouver un sponsor. Une personne qui croit au projet et suffisamment haut placée pour dire : « cette équipe sera autonome et prendra ses décisions seulement en fonction des usagers du service qu’elle développe. ».

Reste alors à l’équipe le plus compliqué : aller parler à celles et ceux qui vont utiliser le produit au quotidien et écouter leurs retours, encore et toujours.

Ce que l’IA n'aura sans doute jamais

Suite à sa défaite de 2016 face au programme AlphaGo, le champion de go Lee Sedol a récemment décidé de prendre sa retraite.

Même si pour le chercheur Antonio Casilli « il n’y a pas d’IA, seulement le digital labor de quelqu’un d’autre », l’apprentissage automatique continue de faire des progrès.

D’autant plus que concernant les jeux, qu’il s’agisse du go ou de StarCraft, les algorithmes n’ont même plus besoin de données d’entraînement péniblement annotées par des humains pour apprendre. Ils jouent désormais les uns contre les autres pour progresser, ce qu’on appelle l’apprentissage par renforcement.

La retraite de Sedol est un signal faible qui laisse entrevoir un futur possible : un monde où les machines nous ont remplacé pour certaines tâches qu’elles réalisent mieux que nous. N’est-ce pas déjà ce qui s’est passé lors de la révolution industrielle où la force des machines à vapeur à supplanter la force animale ?

Si les algorithmes d’apprentissage automatique nous surpassent dans tout un tas de tâches répétitives, que nous restent-ils alors, à nous les humains, que les machines ne posséderont sans doute jamais ? L’émotion.

L’émotion nécessite en effet une connexion physique au monde et aucune intelligence artificielle ne pourra en ressentir sans enveloppe corporelle. Or c’est loin d’être une simple affaire, ne serait-ce que pour des raisons énergétiques. Un cerveau humain comme celui de Lee Sedol consomme 20 W, contre 20 000 W pour AlphaGo, alors que ce dernier ne sait réaliser qu’une seule tâche très limitée finalement.

Le scénario idéal dans un monde d’IA : les machines algorithmiques nous assistent au niveau cognitif, de la même manière que les machines thermiques décuplent notre force physique. Nous pouvons ainsi nous concentrer sur ce qui nous rend au fond humain : la connexion, l’empathie, la bienveillance…

Serons-nous capable de faire en sorte que ce soit ce scénario là qui se réalise ?

L'ouverture par défaut ne passe pas à l'échelle

Récemment, Google a mis fin à deux politiques internes qui faisaient jusqu’alors figure de ruptures par rapport au management traditionnel : le TGIF (un rassemblement hebdomadaire où les employés pouvaient notamment poser n’importe quelle question à la direction) et l’ouverture par défaut de tous les documents internes.

Les questions posées aux TGIF ne pourront désormais porter que sur le travail et les employés devront faire des demandes pour accéder aux documents internes qui ne les concernent pas directement en justifiant qu’ils ont le droit d’en connaître. Comme à l’armée quoi…

Est-ce que cela veut dire que toutes les structures sont amenées à aller vers de moins en moins d’ouverture au fur et à mesure qu’elles grossissent ? Sans doute que oui.

Tout le problème vient de l’échelle. Gérer une entreprise de 100 000 personnes (comme Google) n’a rien à voir avec gérer une entreprise de 1 000 personnes. La complexité n’est pas linéaire.

Rien qu’en comptant le nombre de relations possibles entre employés, le problème saute aux yeux : il y a environ 500 000 relations possibles entre 1 000 employés ; entre 10 000 employés, 50 millions de relations. 100 000 employés ? Cela représente 5 milliards de relations possibles !

Ce simple constat plaide pour une solution évidente : pour rester fluides et ouvertes, les organisations doivent limiter leur taille.

C’est une des raisons du succès de la communauté des incubateurs publics, beta.gouv.fr : au lieu d’un gros organe central captant tous les projets, elle est organisée en réseau de petites structures relativement indépendantes qui partagent une vision commune. La taille de ces structures reste limitée, d’une dizaine à une centaine de personnes.

Pour garder notre ouverture, nous n’avons qu’une seule option : rester petits, multiples et décentralisés !

C'est notre métier

Vous êtes un seigneur au moyen-âge et vous avez besoin d’une nouvelle épée pour vos duels. Vous allez voir le forgeron pour lui en commander une. Imaginez sa tête quand vous lui tendez votre cahier des charges technique qui lui explique comment faire son métier.

Ishan Bhojwani de l’incubateur de la DINUM a raconté cette histoire lors d’un atelier de partage entre incubateurs. Elle résume bien le regard que les dirigeants des grandes organisations portent parfois sur les métiers numériques. Voici nos exigences fonctionnelles et techniques, transformez-les en une application.

Sauf que comme la ferronnerie, le développement logiciel est un métier artisanal. Et le seul moyen qu’un artisan excelle et réalise quelque chose qui nous corresponde est de nous asseoir avec lui pour lui expliquer notre problème. Puis de lui faire confiance, parce qu’il connaît son métier.

Apprendre par l'hybridation

Lors d’une table ronde au sommet des Govtech, une question très pertinente a été posée : comment les administrations peuvent-elles acquérir des technologies dont elles ne connaissent même pas l’existence ?

En tant qu’innovateurs publics, il est important que nous nous emparions de cette question. Comment permettre aux agents de se rendre compte de l’état de l’art des technologies, afin qu’ils puissent imaginer de quoi le futur pourrait être fait.

Deux pistes existent pour y arriver : la formation et l’hybridation.

1/ La formation est le moyen classique d’exposer de nouveaux concepts. On assoit des humains (de préférence des chefs) dans une salle et on leur explique ce qui existe aujourd’hui et de quoi demain sera fait. Puis on espère qu’en rentrant ils partageront tout ce qu’ils ont appris à leurs équipes.

2/ L’hybridation est différente. Il s’agit là aussi d’une formation, mais par la pratique. Le principe est simple : faire travailler sur un projet commun agents publics et experts venus de l’extérieur. Soit on immerge des geeks dans un milieu administratif (comme le programme Entrepreneurs d’intérêt général), soit on plonge un agent dans une équipe de techos (c’est le concept des startups d’État).

Dans les deux cas, tout le monde apprend. Les agents peuvent se rendre compte à travers un projet concret des avancées sur un domaine donné. Et les experts du numérique entrevoient les rouages de l’administration. Ce qui leur donne parfois envie de rester.

« J’entends et j’oublie. Je vois et je me souviens. Je fais et je comprends. » (Confucius)

L’authenticité des politiques sur les réseaux sociaux

Quels points communs existe-t-il entre le républicain Donald J. Trump et la démocrate Alexandria Ocasio-Cortez ? Peu au niveau politique. Mais beaucoup quant à leur image publique et leur parole sans filtre. Ces deux politiciens cultivent en effet l’image de personnes authentiques, loin des élus en costume-cravate au langage poli auxquels nous sommes habitués. C’est d’ailleurs pour cela qu’ils tweetent eux-mêmes. Et c’est pour cela qu’ils ont un nombre considérable d’abonnés.

L’authenticité ne peut pas être feinte quand on multiplie les interactions ; les inauthentiques finissent toujours par se trahir. Or les réseaux sociaux font tout pour multiplier le nombre de ces interactions, et c’est précisément sur ces réseaux que Trump et Ocasio-Cortez s’illustrent.

Pourquoi la parole des authentiques est-elle plus importante de nos jours que par le passé ? À cause de la nouvelle typologie des médias.

Avant, pour vous adresser à vos potentiels électeurs, il fallait passer à la radio ou à la télévision. Le nombre de fréquences disponibles étant limité, ces médias exploitaient leur rareté. Dans ce contexte, les médias de masse, désireux d’augmenter leur audience, étaient obligés d’être consensuels et relativement proches de la moyenne en terme d’idées.

À l’inverse, les réseaux sociaux ont tendance à amplifier les voix dissonantes et excentriques car ce sont elles qui vont être le plus partagées. Les algorithmes de ces plateformes seront toujours capables de leur trouver une oreille attentive, quel que soit le message.

Avec cette redéfinition de l’espace médiatique, qu’on le veuille ou non, il n’y a plus de place pour les discours mesurés et policés. Ne resteront que les voix authentiques, qu’elles crient ou qu’elles murmurent.

–

Pour en savoir plus sur l’utilisation des réseaux sociaux par AOC, cet article de Kéliane Martenon est très complet.

L'égo ou l'ouverture ?

C’est notre projet, ce sont nos données ! Ils doivent nous mettre en avant, et pas les autres.

Combien de fois voyons-nous des projets où des gens de différents départements refusent de collaborer ? Ont peur que d’autres reçoivent les lauriers à leur place ? Considèrent que les données leur appartiennent ? Si vous travaillez dans une grosse structure comme une administration, assez régulièrement j’imagine.

Cette posture est souvent une question d’ego. Parfois une stratégie pour se mettre en avant vis-à-vis des chefs, pour sa carrière. À une époque où l’information (au sens large) était rare, sans doute que cette méthode s’est avérée efficace et permettait à celles et ceux qui la pratiquait d’avoir plus de pouvoir. En limitant le partage, en contrôlant les choses, on avait la maîtrise.

Mais dans un monde où l’information est abondante et disponible partout, tout le temps, le pouvoir ne provient plus du contrôle mais du partage. Et ce n’est plus vraiment du pouvoir, mais plutôt de l’influence. Cette influence provient de la connexion, et appartient à celles et ceux qui créent des liens plutôt que des barrières.

Outre l’abondance de l’information, une autre raison de ce changement de paradigme est l’attention portée aux usagers. Pour créer le meilleur produit possible, il faut sans cesse se concentrer sur celui ou celle qui l’aura dans les mains. Or si nous ne pensons qu’à mettre en valeur notre petit pré carré, impossible de se souvenir qu’il y a des utilisateurs. C’est la raison pour laquelle autant de sites institutionnels sont à chier : chacun ne pense qu’à mettre en avant sa structure, son organisation… au détriment des vraies attentes des utilisateurs. Sauf qu’au final, ne resteront dans le long terme que ceux qui auront été capables de répondre à cette question : qu’est-ce que je peux faire pour vous ?

Commencer avec des bouts de ficelle

Lors d’un hackathon organisé la semaine dernière par l’établissement public territorial Plaine Commune, une des équipes présentait un projet de mise en relation d’agents voulant apprendre quelque chose, avec des agents connaissant ce quelque chose. Leur présentation incluait évidemment une application numérique facilitant ces rencontres apprenantes. Sauf que dans leur plan de lancement, avant de développer une application, ils souhaitaient tester l’idée avec… un simple tableau en liège. On adore !

Soyons honnête, de la même manière que quasiment les deux-tiers des startups disparaissent au bout de cinq ans, les projets de l’administration ont également de grandes chances de foirer. Donc autant tester l’idée le plus simplement et le plus rapidement possible. Mettre un tableau en liège dans un hall et expliquer le principe par courriel coûte moins d’une centaine d’euros et peut être fait en une semaine. Par comparaison, une application coûterait plusieurs milliers, voire dizaines de milliers d’euros, et plusieurs mois de travail.

Évidemment, le nombre d’usagers potentiels n’est pas le même. Avec une solution numérique, l’effet levier est incroyable et le passage à l’échelle infiniment plus aisé qu’avec des tableaux en liège. Mais ce serait mettre la charrue avant les boeufs que de commencer avec un outil numérique. Déjà l’adhésion, la croissance et la vérification que les usagers adorent le concept. Ensuite le passage à l’échelle et l’amélioration de la solution.

J’ai travaillé dans une startup qui ne commençait à développer ses produits qu’une fois les contrats signés. Histoire vraie.

Certains attendent que tout soit parfait pour commencer à innover. Mais les projets qui marchent le mieux sont souvent ceux qui ont commencé avec des bouts de ficelle.

Pourquoi je n'écris plus sur Medium

Ça fait un peu plus semaine déjà que j’ai quitté Medium pour publier mes articles sur ce blog à la place. J’adore Medium. Cette décision n’a donc pas été aisée. Sur Medium, tout est simple et facile : écrire, publier et partager se font sans accroc. On ne pense qu’au texte et n’est-ce pas le plus important finalement quand on écrit ?

Pas seulement. Car il est indispensable de mettre en adéquation ses paroles et ses actes. Or je prône régulièrement le logiciel libre, la souveraineté numérique et le respect de la vie privée.

La première chose qui me dérangeait, c’était de n’avoir aucun contrôle sur la plateforme de publication, alors qu’elle avait du contrôle sur moi. En effet, si demain une fonctionnalité change et que le produit évolue dans une direction qui ne me plait pas, je n’ai pas d’autres choix que de l’accepter. Les logiciels libres comme celui utilisé pour créer ce site permettent à l’inverse de rester maître de nos outils.

La seconde raison de ce changement, c’est la question des plateformes. De la même manière que les serfs cultivaient des terrains qui ne leur appartenait pas, quand nous publions du contenu sur une plateforme, nous travaillons pour elle plutôt que pour nous. Certes, cela est moins vrai avec Medium car son modèle d’affaire repose sur l’abonnement d’utilisateurs plutôt que la publicité, et que la plateforme rémunère une partie des auteurs. Mais en publiant grâce à des outils que je maîtrise de bout en bout, j’ai l’assurance que mon travail sert mon objectif (= contribuer à changer la culture numérique de la fonction publique) et pas ceux d’un acteur tiers.

Ma dernière motivation enfin est celle du respect de la vie privée. Sur ce blog, il n’y a aucun traqueur, aucun cookie, que du contenu (s’il en reste, n’hésitez pas à me prévenir). Non seulement cela rend le site très rapide à charger, mais cela limite également la consommation énergétique associée. En naviguant sur ce site, personne ne sait ce que vous faites, ce que vous aimez, quel est votre navigateur ou votre adresse IP. Et de mon côté, je n’ai pas de statistiques d’utilisation et donc pas d’indicateurs futiles, ce qui est plus reposant. Chacun reste le plus libre de son temps possible.

Maintenant que ce blog a déménagé, comment être quand même informé des nouveaux articles ? Rien de plus simple : pour les modernes, envoyez-moi un courriel et pour les anciens, abonnez-vous au flux RSS.

Pas à armes égales

Vous cliquez sur le lien pour regarder cette vidéo dont le titre vous interpelle. Vous regardez la vidéo et un algorithme commence à vous proposer d’autres vidéos. Vous en sélectionnez une, puis une autre et vous finissez deux heures plus tard à vous demander ce qu’il vient de se passer.

Depuis 1997 et la victoire de Deep Blue sur Kasparov, il est facile de prédire le résultat d’une partie d’échecs entre un humain et une machine. La machine gagne systématiquement. Le même phénomène est en train de se produire sur des jeux beaucoup plus complexes comme le go ou StarCraft 2.

Pour réussir ces exploits, des algorithmes sont entraînés en jouant des milliards de parties afin de déterminer automatiquement les meilleurs stratégies.

Quand nous regardons toute la nuit des vidéos recommandées par un algorithme, nous nous demandons comment nous avons pu être aussi faible. Mais de la même manière qu’en 2019 aucun champion d’échec ne peut battre un simple échiquier électronique à 50 €, nous ne nous battons pas à armes égales quand un algorithme veut que nous restions le plus longtemps possible sur une plateforme.

À chaque recommandation, nous affrontons en fait un algorithme entraîné sur des millions de personnes et des milliards de vidéos. Ce n’est pas nous, humains, qui sommes faibles. Ce sont les machines que nous avons conçues qui fonctionnent un peu trop bien.

Le poids de la transformation

Vous commencez à peser un ananas sur une balance à plateau. L’ananas est sur un des plateaux, en bas à cause de la gravité. Vous ajoutez au fur et à mesure des poids sur l’autre plateau. Au début rien ne se passe. Puis l’ananas commence à monter. Jusqu’à atteindre l’équilibre. Jusqu’à ce que la masse de vos poids soit égale à celle de l’ananas.

Pendant la table-ronde autour du thème « le code fait-il vraiment loi » lors de la restitution du programme EIG, le chercheur Clément Mabi a parlé d’un concept intéressant : il est difficile pour les grosses organisations d’investir dans la transformation numérique car les effets ne se font pas sentir au début.

Elles lancent un programme d’innovation, une formation, un hackathon. Petit poids par petit poids. Sauf que les effets concrets de ces investissements restent invisibles. Pour le Dr Mabi, là réside une des difficultés de la transformation : les effets ne se font sentir qu’au bout d’un certain temps, une fois une masse critique atteinte. Le contrepoids de la culture transformée.

Trois remarques importantes :

1/ Contrairement à une balance qui monte graduellement, il est très difficile de mesurer l’avancée d’une transformation. À partir de combien de magasins bio et micro-brasseries peut-on considérer un quartier est gentrifié ? Il n’y a pas de seuil ou de palier, tout cela est toujours très progressif. C’est pareil pour la transformation numérique.

2/ Contrairement à l’ananas dont la masse est invariante dans le temps, la technologie avance sans cesse. Il n’y a donc pas d’état d’équilibre, pas de moment où nous avons suffisamment agit pour nous dire « c’est bon, tout est transformé, nous pouvons arrêter ». Au lieu de cela, nous devons intégrer l’évolution comme une partie intégrante de nos métiers.

3/ Même si les effets n’apparaissent qu’au bout d’un certains temps, il est nécessaire de montrer que le train est en route et que la transformation a démarré. Pour cela, il faut des exemples concrets et facilement atteignables, pour inspirer et rallier tout le monde à la cause.

Vous n'êtes pas seuls

Hier soir avait lieu la restitution de la troisième promotion du programme « Entrepreneurs d’intérêt général » au ministère de la Transition écologique et solidaire. Au delà de la présentation des projets (incroyable ce qu’ils ont fait en 10 mois) et d’une table-ronde sur un sujet inhabituel (le code fait-il vraiment loi ?), c’était surtout une belle occasion de se retrouver avec une partie de la communauté des innovateurs publics.

Ce point a été souligné comme un élément de la réussite du projet : l’esprit de promotion qu’il existe au sein des EIG. C’est également pour cela que Data for Good est une communauté qui se rencontre principalement IRL : pour faire corps.

Pourquoi est-il si important de se rassembler ? Parce que quand nous cherchons à transformer une culture, il est inévitable de rencontrer une certaine incompréhension, voire une forme rejet de la part de la culture dominante. C’est naturel. Mais c’est parfois fatiguant. Comme ramer toujours à contre-courant.

Alors pendant une après-midi, pendant une soirée, il est agréable d’être avec des pairs déjà convaincus des méthodes et qui ont rencontré les mêmes difficultés que nous.

La difficulté, c’est de réussir à créer ce sentiment de communauté tout en restant inclusif. Comment faire en sorte que tout le monde puisse avoir ce sentiment de faire partie du même groupe, sans générer de sentiment de « eux contre nous » ?

La clef pour réussir à faire cela : rendre ces communautés ouvertes et facilement accessibles. Chez Data for Good, tout le monde est bienvenu et le critère principal pour participer est la motivation. Dans le programme EIG, la communauté ne désigne pas seulement les geeks qui sont embauchés pour l’occasion, mais aussi les mentors des administrations qui ont souvent passé tout leur carrière dans l’administration.

Créer des communautés ouvertes est complexe, mais c’est un élément indispensable à toute transformation culturelle. Car cela nous rappelle une chose : nous ne sommes pas seuls.

Une nouveauté dans le système d'exploitation

Dans sa biographie « Permanent record », le lanceur d’alerte Edward Snowden utilise une expression marquante : « […] my country’s operating system—its government […] ». Pour lui, le gouvernement est comme le système d’exploitation d’un pays.

À la manière dont Windows, MacOS ou une distribution Linux sont capables de transformer ce gros tas de métal et de silicium qu’on appelle un ordinateur en un outil magique, le gouvernement serait ainsi capable de concrétiser le concept de pays.

Pour filer la métaphore, la constitution représenterait le firmware qui contient les instructions nécessaires à l’allumage du système, les agents joueraient le rôle du processeur, utilisant leur intelligence pour transformer des informations, le système d’archives nationales serait l’équivalent du disque dur où sont stockées les données pour le long terme.

Que représentent alors les nouveaux modes d’innovation publics comme les startups d’État ou le programme « Entrepreneurs d’intérêt général » ? Une mise à jour ? Un nouveau logiciel ? Un virus ?

Et si nous faisions des startups d'État européennes ?

Je reviens d’un voyage de quelques jours en Lettonie où j’ai eu la chance de pouvoir parler de mes deux sujets préférés : l’innovation publique et les questions d’éthique liées aux algorithmes d’apprentissage automatique. Deux choses m’ont marqué par rapport à ces thèmes.

L’éthique des algorithmes est devenu un sujet grand public

L’institut français de Lettonie m’a invité à un fireside chat pour parler éthique et IA. Je me suis donc exprimé sur la connexion forte qui existe entre les deux sujets à travers la notion partagée d’objectif, sur les risques lorsque ces objectifs sont masqués et les pistes existantes pour tenter d’améliorer les choses.

J’ai été surpris par la taille et la diversité de l’audience : une cinquantaine de personnes (soit la capacité maximale de la salle) était présente un mercredi soir, pour écouter une conférence sur un sujet technique, qui n’était même pas pour certains dans leur langue natale. Des hommes et des femmes de vingt à quatre-vingts ans étaient là pour essayer d’en savoir plus sur des concepts dont ils sentent l’importance mais dont on n’entend parler que depuis récemment. Depuis nos premiers travaux en 2017, au sein de Data for Good ou d’AlgoTransparency, l’intérêt pour ces questions est croissant et cela fait plaisir au regard de leur importance.

L’innovation publique pourrait profiter à l’Europe

Pendant ce séjour, j’ai eu l’opportunité d’échanger avec des représentants d’administrations locales. Grâce au séminaire que j’ai animé sur l’innovation publique, j’ai également pu partager avec des fonctionnaires du Kosovo, du Monténégro ou de Bosnie-Herzégovine. J’en tire un double constat. Premièrement, les administrations de tous ces pays ont les mêmes difficultés que les nôtres pour innover et créer des services publics numériques. Les administrations et leurs sous-ensembles fonctionnent en silo, les compétences internes sont rares et l’autonomie manque souvent cruellement. Pourtant comme en France, les citoyens réclament de plus en plus de fluidité et de facilité dans leurs relations avec l’État.

Les programmes comme Entrepreneur d’intérêt général et startups d’État semblaient radicaux et prometteurs à ceux à qui je les ai présentés, tout comme ils devaient semblé radicaux et prometteurs aux membres d’Etalab qui les ont ramenés des États-Unis. Avec tous les produits et services qui ont déjà été réalisés dans ces cadres, l’Europe ne serait-elle pas une bonne occasion de les faire passer à l’échelle et de commencer à construire des outils communs ? Chaque pays pourrait dès lors apporter son expertise (par exemple la France pour la codification de la loi ou la Lettonie pour la numérisation des ordonnances) et bénéficier de celle des autres. Quoi de mieux pour raviver le sentiment européen sinon que de construire un avenir numérique en commun, en ce lendemain des 30 ans de la chute du mur de Berlin ?

Le seul critère pour être volontaire à Data for Good

Pendant le temps où j’ai fait partie de l’équipe organisatrice de Data for Good, plus de mille volontaires se sont inscrits sur notre site pour proposer leurs compétences en science des données, développement ou design. Trois grands types de profil se dégagent parmi les bénévoles :

1/ Les étudiants encore à l’école et qui souhaitent appliquer ce qu’ils apprennent à des cas concrets, pour le bien commun. Cela leur apportent en plus des projets à ajouter à leur portfolio ce qui est de nos jours parfois plus important que le diplôme.

2/ Les employés de grosses structures, type banque, conseil ou assurance qui trouvent que leur travail manque de sens. L’association a pour eux une sorte de fonction expiatoire et leur donne l’occasion de se sentir utile à la société.

3/ Les employés de startups technologiques excités par les nouveaux défis et le fait de pouvoir tester de nouvelles technos. À côté de Data for Good, ils sont souvent engagés dans trois ou quatre autres projets et passent leur week-end dans des hackathons ou à se battre pour le leaderboard de Kaggle.

Ces catégories sont évidemment réductrices et les parcours des bénévoles sont souvent un mélange de ceux cités plus haut.

Peu importe.

En observant les volontaires les plus impliqués dans les projets, cela n’a jamais été une question de diplôme, d’expérience professionnelle ou de connaissance technique.

Un seul critère est pertinent : l’enthousiasme, l’envie, bref, la motivation.

C’est cette motivation qui fait que des volontaires qui ne se connaissent pas sont prêts à passer des soirées et des week-ends pour des projets auxquels ils croient. Dans l’organisation de Data for Good, tout est donc pensé pour que les bénévoles soient enthousiastes et le restent (NB : « pensé » est un bien grand mot ; « trouvé par tâtonnement » serait plus exact).

Le formulaire d’inscription, par exemple, comporte treize questions et demande une vingtaine de minutes pour être complété. Nous aurions pu ne demander que l’adresse e-mail mais cette première friction agit comme un filtre : 58 % des gens ne remplissent pas le formulaire jusqu’au bout.

Autre exemple, lors des journées de lancement, chaque volontaire peut choisir le projet qu’il ou elle préfère, sans limite dans la taille des équipes. Cela génère parfois de grosses équipes, ou des projets qui ne trouvent pas de bénévole. Mais le plus important est que chaque personne qui a choisi de donner de son temps puisse être sur son projet préféré, celui qui le fait vibrer et qui lui parle.

Dans une association où tout le monde est bénévole, quelle est la colle qui peut faire tenir toute une communauté ensemble si ce n’est la motivation ?

Article publié à l’origine sur Medium.

L’innovation cyclique

Dans le MOOC du CNAM « Fabriquer l’innovation » tout un chapitre est consacré à la création du Minitel. Une des choses frappantes dans cette histoire est la similarité de certaines idées de l’époque avec des concepts très contemporains.

L’UX design, par exemple, existait déjà dans les années 80. Plutôt que de balancer des Minitels à tous les Français en mode gros bourrin, la Direction générale des Télécommunications (DGT, ancêtre de France Télécom, ancêtre d’Orange) a décidé de tester l’utilisabilité de ce dispositif, censé remplacer l’annuaire papier, en Ille-et-Vilaine. Cette expérience a permis de mettre en lumière quelques limites du système :

• Faire une recherche prenait plus de temps que sur l’annuaire papier ;
• Les utilisateurs avaient du mal avec le clavier alphabétique car ils étaient déjà habitués à l’AZERTY à cause des machines à écrire ;
• Le système n’avait aucune tolérance quant aux fautes d’orthographe ;
• Avoir une seule fonctionnalité (l’annuaire) n’était pas suffisant.

Le bénéfice de cette expérience est double pour la DGT : les connaissances acquises permettent de faire évoluer le modèle et l’implication des usagers facilite l’acceptation du système. Pour résoudre la question des fonctionnalités, un nouveau dispositif est imaginé : le kiosque. Il s’agit de permettre à des éditeurs de déployer des services payants sur le Minitel. La DGT gère la facturation et reverse deux tiers de l’argent aux éditeurs. Ce modèle de gestion centralisé de services et son modèle économique rappellent furieusement celui qui a fait le succès de l’iPhone : l’App Store d’Apple. Le pourcentage reversé aux développeurs par l’entreprise y est d’ailleurs de 30%.

Sur ce kiosque, de nouveaux services apparaissent et ressemblent déjà à ceux qui seront plus tard disponibles sur internet (à ceci près qu’il n’y a pas de souris sur le Minitel et qu’il faut donc tout faire au clavier). Dès les années 80, il est donc possible de lire le journal, de consulter ses comptes ou même de discuter en ligne depuis son salon. Et signe avant-coureur de l’importance de l’industrie du porno sur internet, plus de la moitié des revenus tirés du Minitel viennent des « messageries roses ».

Évidemment, depuis le Minitel, beaucoup de choses ont évolué, de la puissance de calcul et la taille réduite des appareils, à la simplification des interfaces. Mais pour les innovateurs, il est souvent utile de regarder dans le rétroviseur : à la fois pour y puiser de l’inspiration, mais également pour prendre une bonne dose d’humilité en remarquant que beaucoup de belles choses ne nous ont pas attendu pour être inventées.

Article publié à l’origine sur Medium.

La méthode « startup » : trier le bon grain de l’ivraie

Dans « startup d’État », il y a « startup » (merci Captain Obvious). Cela sème parfois la confusion et nous sommes obligés d’expliquer que ce sont seulement les méthodes des startups que nous utilisons, mais que nos produits sont fait par l’État et pour l’État (ou plutôt pour ses concitoyens).

Est-ce que cela veut dire que nous reprenons exactement le fonctionnement des startups ? Évidemment non. Nous nous efforçons de n’en garder que les meilleurs aspects, et d’en retirer les moins bons.

Ce que nous avons garder :

1/ La responsabilité et l’autonomie. Dans une startup, il y a beaucoup plus de boulot que d’employés pour le faire. Des juniors se retrouvent ainsi lead développeur ou jonglent parfois entre trois casquettes différentes. Et de toute façon, personne n’a le temps de micro-manager parce que la levée du fond met du temps à arriver et que la trésorerie est bientôt dans le rouge. Le seul moyen pour que cela fonctionne, c’est de recruter des personnes talentueuses, de leur donner un objectif et de les laisser faire leur travail en autonomie.

2/ Produit minimum viable et déploiement continu. Pour s’assurer de la justesse de leurs hypothèses, les startups sont obligées de sortir très rapidement la première version de leur produit. Et pour s’assurer que le produit est d’une qualité exceptionnelle pour les clients, il est indispensable de le modifier rapidement et régulièrement pour prendre en compte leurs retours. Cela a des implications techniques car il faut être capable de tester et de déployer du code facilement et automatiquement.

3/ L’importance de la culture. Chaque startup affiche fièrement sa mission, sa vision, ses valeurs, etc. C’est aspect culturel peut sembler trivial mais dans un contexte où les nouveaux arrivants sur le marché du travail sont plus que jamais en quête de sens, avoir une culture forte est un élément différenciant important. De plus, vu la croissance rapide des jeunes pousses, il est nécessaire de se mettre d’accord dès le départ sur une culture commune, afin de garder une certaine stabilité une fois que le nombre d’employés aura été multiplié par dix ou par cent.

Nous ne sommes néanmoins pas naïfs et la culture startup peut avoir des aspects toxiques que nous faisons tout pour ne pas importer.

a/ Le présentéisme. Comme il y a beaucoup de travail, les employés des startups ont tendance à faire beaucoup d’heures. À tel point que dans certaines discussions entre employés, il n’est pas rare d’assister à des batailles pour savoir qui a fait le plus de nuits blanches ou qui a travaillé tout le week-end. Dans la fonction publique, le travail qui doit être fait est fait mais nous avons des horaires normaux, qui nous permettent de profiter des autres aspects de la vie, comme sortir avec ses potes ou passer du temps avec sa famille. De toute façon, les gens reposés travaillent mieux !

b/ Le côté boys’ club. Dans certaines boîtes, la culture peut être assez misogyne, avec une équipe dirigeante qui ressemble parfois à un BDE d’école de commerce. De plus la culture “bro” présente dans le milieu de la technologie peut s’avérer inhospitalière pour certaines personnes. Sans virer dans le côté social justice warrior, nous faisons en sorte que chacun et chacune se sente à sa place au sein de notre incubateur.

c/ Le design centré revenu. Quand une entreprise doit choisir entre ses clients et sa rentabilité, il est très difficile de choisir les premiers au détriment du second. En même temps, il faut bien continuer à payer les salaires. Mais parfois le problème est encore plus complexe : les clients et les usagers du produit ne sont pas les mêmes. Pour toutes les startups sur le crédo de l’économie de l’attention, le client est celui qui achète l’attention alors que l’usager est celui qui la fournit. Du côté du secteur public, même si les bureaucrates veulent évidemment créer des produits qui leur facilite la vie, plutôt que celle des usagers, il est quand même possible de faire du design vraiment centré sur l’utilisateur.

Comme dans toutes choses, il y a à prendre et à laisser dans la culture et les méthodes des startups. Et qui sait, peut-être qu’un jour ce sont les startups qui s’inspireront de la culture et des méthodes des startups d’État ?

Article publié à l’origine sur Medium.

Éthique et algorithme : une question d’objectif

Qu’est-ce qu’une éthique ? La proposition de se rapprocher d’un objectif de vie, en suivant une certaine voie. Les éthiques antiques par exemple se concentrent souvent sur la recherche du bonheur. Contrairement aux morales qui imposent, les éthiques recommandent : « tu devrais » plutôt que « tu dois ».

Les algorithmes, notamment ceux utilisés pour l’apprentissage machine (machine learning), essaient eux aussi d’atteindre des objectifs. Pour apprendre en effet, il faut connaître ce que l’on recherche afin de savoir vers quoi il faut s’orienter. Un algorithme de reconnaissance faciale a par exemple pour objectif de reconnaître des visages. Pour mesurer s’il remplit correctement sa mission, cet algorithme est testé sur des images qu’il n’a jamais vu pendant sa période d’apprentissage pour vérifier s’il est capable de les reconnaître correctement. « Correctement » peut ici avoir plusieurs significations, selon que nous souhaitions limiter les faux positifs ou les faux négatifs par exemple.

La question principale dans le débat autour de l’éthique et de l’intelligence artificielle peut donc se résumer ainsi : est-ce que les objectifs des algorithmes sont alignés avec les nôtres ?

Imaginons un algorithme chargé d’élaborer les menus d’une cantine scolaire. Son objectif est de s’assurer que les assiettes sont toutes vides à la fin du repas. S’il s’aperçoit pendant sa période d’apprentissage que les aliments très salés et très sucrés remplissent cette mission, il finira sûrement par ne servir que des frites, des nuggets et des glaces.

Le choix de ce genre d’objectif pour les algorithmes prédictifs peut donc générer des effets secondaires indésirables. Pourquoi alors est-ce que ce sont ces objectifs qui sont choisis ? Parce qu’il est facile de mesurer si l’on s’en rapproche, grâce des capteurs physiques ou virtuels. Quantifier ce qu’il reste dans les assiettes d’une cantine est simple : il suffit de peser le poids des poubelles à la fin du service. Mais mesurer si les enfants sont en bonne santé (ce qui devrait finalement être l’objectif de notre algorithme-cuisinier) est excessivement plus complexe, voire intrusif.

Le sujet de la pertinence du pilotage par des indicateurs mesurables est vaste et se rencontre également dans d’autres domaines comme l’administration où le débat fait rage (voir cette discussion passionnante). Mais concernant l’intelligence artificielle (comme disent les marchands), centrer la discussion sur les objectifs permet de faire un pont entre la technique (quel est la fonction objectif de l’algorithme ?) et l’éthique (quel est l’objectif de la vie humaine ?). Et cela permet enfin de s’affranchir de la complexité grandissante des modèles utilisés, pour se recentrer sur une question simple : qu’est-ce que les algorithmes sont censés faire pour nous ?

Article publié à l’origine sur Medium.

Sortez du bâtiment pour tester votre produit

« Et qu’en disent les utilisateurs ? »

Si cette simple question était posée de manière systématique, la majorité des problèmes posés par les produits développés par les administrations seraient résolus.

Ce n’est pas une posture facile à avoir. Sortir de son bureau et aller parler à des humains est tellement plus difficile que de rester enfermer avec son équipe à imaginer les éventuels comportements et réactions de ces derniers.

Plusieurs raisons font que nous oublions souvent de demander l’avis de celles et ceux qui vont avoir le produit dans les mains :

1/ Cette culture tout d’abord, façonnée depuis l’école où l’on nous a expliqué qu’il y a d’un côté ceux qui savent, et de l’autre ceux qui reçoivent le savoir. Donc si c’est nous qui sommes chargés de construire le produit, c’est que nous devons posséder le savoir, non ? Sauf que le savoir technique (comment coder une application) n’apporte aucune réponse sur la manière dont les utilisateurs vont utiliser notre produit. C’est même souvent l’inverse : si vous laisser seuls des ingénieurs développer un logiciel, ce dernier risque d’avoir de nombreuses fonctionnalités tellement complexes que personne ne saura les utiliser. Il faut donc écouter les utilisateurs, car eux seuls vont pouvoir vous dire si votre produit est suffisamment simple et utilisable.

Faire des tests, ne serait-ce qu’avec un seul utilisateur, apprend énormément. Quand j’étais à l’Agence du numérique, un proche (habitué à utiliser un ordinateur) m’a servi de cobaye sur un forum que je mettais en place. Je l’ai mis devant le site en lui demandant seulement de créer un nouveau sujet sur le forum. Au bout de cinq minutes, il n’avait toujours pas trouver comment faire. Avec un unique utilisateur, j’ai compris que mon site était trop compliqué et que j’allais devoir revoir ma copie.

2/ Le profil psychologique des geeks ensuite jouent un rôle dans cet état de fait. Même si c’est un stéréotype, la plupart des développeurs que je connais sont plutôt introvertis. Cela semble plutôt normal : vouloir passer plusieurs heures seul devant un écran, ce n’est pas trop le kif pour un extraverti. Et de la même manière, sortir du bâtiment pour parler à des inconnus, ce n’est pas trop le kif pour un introverti. C’est pour cela qu’il est indispensable d’avoir des designers (introvertis ou extravertis) dans une équipe produit : pour aller parler aux sacs à viande et essayer de comprendre pourquoi ils ne sont pas foutus de cliquer sur le bouton que nous avions pourtant mis au bon endroit 😅

Quand nous avons intégré des designers au sein des équipes de volontaires de Data for Good, la qualité des projets a fait un bond en avant. La première fois que vous vous rendez sur la page d’accueil d’AlgoTransparency par exemple, vous n’avez pas des dizaines d’informations qui vous sautent à la figure. À la place, vous avez une introduction didactique qui présente le projet et prend le temps de raconter ce que vous allez trouver sur le site. Tout cela été pensé par des designers et testé auprès de vraies personnes.

Sortir du bâtiment, c’est sortir de notre zone de confort. C’est effrayant car il a de grande chance que nous nous plantions, et notre cerveau reptilien n’aime pas tellement prendre ce genre de risque. Mais rappelons à notre cerveau reptilien qu’il vaut toujours mieux se planter aujourd’hui devant une personne, plutôt que demain devant des milliers.

Article publié à l’origine sur Medium.

Numérique et wabi-sabi

Publié en 1994, l’essai « Wabi-Sabi: for Artists, Designers, Poets & Philosophers » de Leonard Koren a contribué à populariser le terme de wabi-sabi (侘寂) en Occident. Il s’agit d’un concept esthétique japonais renvoyant à la simplicité, à la terre, à l’imperfection, aux marques laissées par le temps qui passe…

L’histoire du wabi-sabi est liée à la cérémonie du thé japonaise et au zen. Au seizième siècle, des maîtres commencent à utiliser lors de leurs cérémonies des poteries humbles et fabriquées par des artisans locaux, au lieu de la porcelaine luxueuse et ultra-décorée qui était la norme jusqu’alors. Ils arrivent à changer la perception par l’élite de ce qu’est le luxe : non plus un salon de thé doré à l’or fin et remplie de vaisselle fine, mais plutôt une modeste cabane de paysan et des tasses rustiques.

En ce qui concerne le numérique aujourd’hui, il semble que nous soyons encore en plein dans les dorures. L’esthétique moderniste qui nous entoure valorise ce qui est lisse, pure et rectiligne. Parce qu’effectivement, le modernisme se veut pratique, facile à utiliser et sans ambiguïtés, ce qui en fait un partenaire idéal pour nos applications « centrées utilisateur ».

Mais si nos applications sont faciles à utiliser, la nature, elle, est plaisante à contempler. Personne ne passe des heures à admirer un site web alors qu’observer les étoiles, regarder le soleil se coucher ou se balader dans la forêt sont encore des activités répandues chez les humains. Face aux infinies variations imprévisibles qu’offre la nature, l’absence d’aspérités du monde de l’écran manque souvent de poésie.

Comment alors rajouter du wabi-sabi dans nos produits numériques si policés ? De l’impermanence, de l’imperfection, de l’incomplétion ?

Le seul wabi-sabi visible à l’heure actuel, ce sont ces écrans cassés de smartphone qu’ont tous les adolescents. Ces écrans qui accrochent le pouce et rendent invisibles certains pixels. Ces écrans qui nous renvoient au temps qui passe et laisse partout sa marque.

À quand une éclosion de l’esthétique wabi-sabi dans le numérique ? Est-elle seulement possible ?

Article publié à l’origine sur Medium.

Pas d’innovation sans autonomie

Il y a quelques années, je postulais pour un poste dans le secteur public au sein d’une équipe qui souhaitait créer un département innovant sur un nouveau sujet. Les entretiens se passent bien jusqu’à ce que le chef de mon futur chef hypothétique me dise « il va falloir être innovant, mais pour chaque sujet, tu vas devoir me convaincre, puis convaincre mon chef, et le chef de mon chef… ». Limite c’est le Premier ministre qui doit valider mes congés en fait… Comment innover dans ce genre de contexte ?

Imaginons que l’évolution fonctionne de la même manière. Le seul moyen d’évoluer serait qu’un brin d’ADN convainque toute sa hiérarchie qu’il a trouvé le plan parfait et qu’une fois ce plan exécuté, c’est sûr, il va pouvoir se dupliquer très facilement. Les espèces seraient assez mal barrées et se ferait décimées à chaque micro-changement d’environnement.

L’innovation requiert un bac à sable, dans lequel il est possible de tester, d’échouer, de re-tester, de re-échouer afin de peut-être finir par aboutir à quelque chose qui fonctionne mieux que ce qui se faisait avant. Et recommencer sans cesse.

C’est la raison pour laquelle une équipe qui innove doit être autonome, la raison pour laquelle le contrôle a priori tue l’innovation : il est indispensable de procéder par essai-erreur pour réussir à faire quelque chose de nouveau. S’il était possible de faire ça en enfermant dans un bureau avec des gens intelligents qui vont trouver un plan sans faille, ça se saurait, et cela serait beaucoup plus simple. Mais il est malheureusement nécessaire de tâtonner, de rester humble et d’écouter les autres.

Être autonome ne veux pas dire qu’il ne faut pas rendre des comptes. Dans la fonction publique, l’argent que nous utilisons vient de la contribution de tous. Nous avons donc une obligation légale mais également morale de bien le dépenser. Mais cette bonne gestion des deniers publics passe par l’optimisation de ces procédés de test et d’apprentissage, plutôt que par un Gosplan. Donnez nous un objectif clair et de l’autonomie, nous nous occupons du reste.

Article publié à l’origine sur Medium.

L’agilité ne peut pas être un dogme

« Nous découvrons de meilleures approches pour faire du développement logiciel, en en faisant nous-mêmes et en aidant les autres à en faire. Grâce à ce travail nous en sommes arrivés à préférer et favoriser :

• les individus et leurs interactions plus que les processus et les outils ;

• un logiciel qui fonctionne plus qu’une documentation exhaustive ;

• la collaboration avec les clients plus que la négociation contractuelle ;

• l’adaptation au changement plus que le suivi d’un plan.

Cela signifie que bien qu’il y ait de la valeur dans les éléments situés à droite, notre préférence se porte sur les éléments qui se trouvent sur la gauche. » (les quatre valeurs du Manifeste agile)

Une question que je me pose souvent, c’est si celles et ceux qui vendent de l’agile à de grandes organisations, et celles et ceux qui achètent de l’agile dans ces mêmes grandes organisations, ont déjà lu ne serait-ce que les quatre valeurs du Manifeste agile.

La phrase « les individus et leurs interactions plus que les processus et les outils » me semble par exemple limpide. Pourquoi est-ce que des cabinets arrivent alors à vendre des méthodes soit disant agiles basées sur des processus et des outils tellement tarabiscotés que toutes les équipes doivent être formées et certifiées. D’un point de vue business, l’objectif est compréhensible, mais d’un point de vue agile, il y a un loupé.

Si nous voulons vraiment favoriser les individus et leurs interactions, il faut passer du temps avec les équipes, à essayer de comprendre ce qui ne fonctionne pas, et surtout proposer des solutions sur-mesure plutôt que sous copyright. Ce n’est pas aux organisations de s’adapter à la méthode, c’est aux méthodes de s’adapter à l’organisation (même si cela ne veut pas dire qu’il n’y a rien à transformer dans le fonctionnement de ces organisations).

De même, le fait de préférer « l’adaptation au changement plus que le suivi d’un plan » ne me semble pas spécialement ambiguë. Pourquoi existe-il alors des règlements expliquant quelle est la bonne manière de mener de projets en mode agile ? L’agilité est par essence orthogonale à l’orthodoxie.

Il existe quand même un avantage à ces règlements : ils permettent à celles et ceux qui voudraient utiliser les concepts de l’agile de manière non dogmatique d’avoir un document qui les protège et justifie leurs pratiques.

Ce caractère très flexible de l’agile, cette impossibilité de le normer est ce qui fait toute sa force. Car les valeurs tels que « suivi d’un plan » ou la « documentation exhaustive » ne sont pas balayées de la main, ce ne sont pas des interdits comme il peut y en avoir dans les textes religieux. Ce sont seulement des valeurs préférables par rapport à d’autres. Et reste aux humains d’utiliser leur cerveau pour savoir ce qui est préférable à un instant donné, avec discernement, intelligence et subtilité, c’est-à-dire sans dogmatisme.

Article publié à l’origine sur Medium.

La transparence des comptes de Data for Good

Aux débuts de Data for Good, l’association fonctionnait pratiquement sans argent. Les seules dépenses étaient l’abonnement annuel à Meetup pour gérer nos événements, la licence Strikingly pour le site et notre nom de domaine. Les salles nous étaient toujours prêtées gratuitement par des entreprises qui croyaient en notre mission (et en profitaient pour rencontrer de potentielles futures recrues 😀). C’est d’ailleurs toujours le cas.

En grossissant, nous sommes rester frugaux et nous ne dépensons que quelques centaines d’euros par an. Nous n’avons pas d’employé et la plupart de cette somme part donc dans les viennoiseries que nous offrons lors des lancements de saison, ou dans les bières et les cacahuètes partagées lors des demo day. Les volontaires s’investissent tellement sur les projets que la moindre des choses est de leur remplir l’estomac.

Traditionnellement, ces frais étaient payés par les membres de l’équipe d’organisation et à de nombreuses occasions remboursés par Bayes Impact, notre grand frère qui nous a toujours soutenu.

L’année dernière nous avons changé de modèle : nous utilisons maintenant Open Collective pour récolter des dons. Les volontaires donnent de l’argent en ligne, et n’importe qui peut avancer une dépense et se faire ensuite rembourser via la plateforme. Les frais sont un peu élevé (5% pour les dons et des frais PayPal pour les remboursements) mais cela nous permet d’éviter les banques et de soutenir un acteur qui partage nos valeurs (leur code est open source). De plus, les donateurs peuvent faire des dons récurrents, ce qui nous permet de nous projeter avec un budget estimatif.

Mais surtout, la meilleure fonctionnalité d’Open Collective est que toutes les transactions sont transparentes. N’importe qui peut savoir d’où vient l’argent et comment il est dépensé. Ce modèle devrait être la norme pour toutes les associations recevant des dons du public : une complète transparence sur la manière dont est dépensé l’argent récolté, transaction par transaction, y compris les salaires.

Pour aller encore plus loin, cela pourrait également être le modèle de la fonction publique : une complète transparence sur la manière dont est dépensé l’argent récolté, transaction par transaction, y compris les salaires. Car l’administration n’est-elle pas finalement une association recevant des « dons » du public qui aurait réussi ?

Article publié à l’origine sur Medium.

Quelle est la culture que nous voulons ?

Dans son livre « Sapiens », Yuval Noah Harari explique que l’atout principal de l’Homo sapiens n’est pas son talent à construire des outils complexes (l’Homo neanderthalensis y arrivait très bien lui aussi) mais plutôt sa capacité à croire en des mythes communs qui vont fédérer des groupes d’individus.

Ce qui défini notre espèce, c’est donc finalement l’innovation sociale plus que l’innovation technique. En effet, une des caractéristiques qui nous rend uniques est que nous sommes capables de changer radicalement de culture, alors que nous gènes restent quasiment identiques.

Chez toutes les autres espèces, le changement de culture va forcément de pair avec un changement biologique et doit donc emprunter le long chemin de l’évolution. Côté humain, pour reprendre un exemple d’Harari, un centenaire né en 1900 à Berlin aura successivement vécu dans un empire, une république, un régime nazi, puis communiste, avant de finir ses jours dans une Allemagne réunifiée. Et tout cela avec le même code génétique. Car nous sommes capables de nous adapter à des cultures différentes, ce qui est exceptionnel dans la nature.

Concernant la transformation numérique à laquelle font face la plupart des grandes organisations en ce moment, cela signifie que le changement de culture est au moins aussi important que la transformation technologique.

Mais quelle est cette nouvelle culture vers laquelle nous voulons tendre, ce mythe qui nous fédère ? Pour nous, cela repose sur trois piliers : la confiance, l’ouverture et l’empathie par défaut.

1/ Confiance par défaut. Plutôt que de donner aux équipes un mode d’emploi leur expliquant comment faire leur métier, nous leur offrons de l’autonomie et la responsabilité de leur produit. Le fonctionnement est le plus horizontal possible et nous nous concentrons sur la qualité de ce que nous faisons plutôt que sur le nombre d’heures passées au bureau.

2/ Ouverture par défaut. À cause de la sensibilité de certains sujets, les agents de notre ministère ont l’habitude de partager l’information de manière restreinte. Dans nos équipes, nous travaillons sur des sujets assez peu sensibles, et s’agissant par exemple de notre messagerie instantanée, nous utilisons de préférence les canaux publics afin que tout le monde ait le même niveau d’information. Nous partageons également les codes sources de nos applications, car qui dit argent public dit code public.

3/ Empathie par défaut. Que nous soyons fonctionnaires, contractuels, freelances, civils ou militaires, tout le monde fait partie de l’équipe. Les bonnes idées viennent de n’importe où et se moquent royalement de nos contrats de travail. De la même manière, nous incluons systématiquement les utilisateurs de nos produits à chaque étape, parce que nous n’avons pas la science infuse et que nous souhaitons vraiment les comprendre.

Cette culture grandit chaque jour au sein de la fonction publique, en prouvant sa valeur à travers la qualité des produits que nous livrons régulièrement. Certes, elle est encore minoritaire mais l’histoire nous a appris que les cultures humaines changent rapidement, sans que nous soyons obligés d’attendre la lente évolution naturelle.

Article publié à l’origine sur Medium.

Développer un logiciel, ce n’est pas construire un bâtiment

« Release early. Release often. […] » (Eric S. Raymond)

La première fois que j’ai assisté à une réunion concernant un projet informatique dans l’administration, j’ai cru que je m’étais trompé de salle. Tout le monde parlait d’AMOA (assistance à maîtrise d’ouvrage), de MOE (maîtrise d’œuvre) et de CCTP (cahier des clauses techniques particulières)… Moi qui avait justement bifurqué du génie civil vers la data science, le destin m’avait rattrapé.

Pour construire un bâtiment, les architectes et les ingénieurs conçoivent des plans détaillant précisément ce qui doit être ensuite réalisé par les ouvriers. Il y a toujours des imprévus, mais globalement tout bien rodé et les bâtiments finissent par être construits, pour des siècles et des siècles.

Malheureusement, cette méthode a été calquée pour le développement des logiciels, notamment dans les grandes organisations, alors qu’il existe quand même de sacrées différences entre une tour de bureau et un site web :

1/ Le coût du changement. Si quelqu’un se rend compte qu’il n’y a pas de toilettes dans les étages 12 à 25 une fois votre immeuble fini, vous avez un gros problème. À l’inverse, le coût nécessaire pour modifier une fonctionnalité d’un logiciel est plutôt faible s’il a été conçu de manière suffisamment modulaire. De plus, il est possible de commencer petit et de faire grossir le projet ensuite, alors que si le constructeur de votre maison neuve vous explique qu’il n’y a que les chambres, mais rassurez-vous, la salle de bain arrivera dans trois mois, vous avez encore une fois un gros problème.

2/ La séparation des rôles. Dans le bâtiment, les ingénieurs prennent les décisions et les ouvriers réalisent les travaux. Dans le logiciel, ce sont les ingénieurs qui ont les mains dans le cambouis numérique, ce sont eux qui construisent. Séparer les rôles et ne considérer les équipes techniques que comme des petites mains est un gâchis énorme. Mieux vaut donc intégrer tout le monde lors des moments de conception des produits numériques.

3/ L’effet levier. Pour construire dix bâtiments, il faut environ dix fois plus d’employés que pour construire un bâtiment. Dans le numérique cependant, il est possible de construire une application utilisée par des millions de personnes avec une dizaine de personnes. L’équipe d’Instagram comptait par exemple treize salariés au moment du rachat de l’entreprise par Facebook en 2012, et leur application avait été téléchargée plus de vingt millions de fois.

4/ La tenue dans le temps. Les cathédrales sont construites en pierre et non en bois car elles sont prévues pour durer (il y a aussi une question de résistance des matériaux, mais vous comprenez l’idée). Côté informatique, les langages de programmation, le matériel, les besoins et même les goûts des utilisateurs changent tellement souvent qu’il est illusoire de penser qu’un produit numérique peut continuer à rendre service durant des décennies sans intervention. Il faut donc voir ces produits comme des éléments vivants, évoluants sans cesse pour s’adapter aux changements constants.

Développer un logiciel s’apparente plus à bricoler dans un bazar qu’à construire une cathédrale. Il serait donc peut-être temps de faire évoluer notre vocabulaire, afin de transformer aussi petit à petit notre culture.

Article publié à l’origine sur Medium.

Les idées et ceux qui les réalisent

Une histoire m’a marqué lors d’une saison d’accélération de Data for Good. Pour celles et ceux qui ne connaissent pas le concept, il s’agit de proposer des projets à des volontaires qui vont plancher dessus pendant trois mois, jusqu’à la présentation de leur travail lors d’un demo day.

Lors du lancement de la saison 4, un groupe de volontaires vient me voir car un des projets présentés les intéresse et ils veulent savoir quand le porteur est censé arriver. Normalement ce sont les porteurs qui présentent eux-mêmes leurs projets mais ce dernier n’étant pas venu, nous avons pris le relais avec l’équipe organisatrice. Je suggère aux bénévoles de démarrer sans attendre et ils commencent alors à phosphorer sur un concept de magazine portant sur les enjeux éthiques autour des données.

En résumé : une équipe de volontaires, au sein de laquelle personne ne se connait et que personne ne dirige, décide de travailler sur un projet qui lui tient à cœur. Et trois mois plus tard, lors du demo day, elle présente La Data en Clair, un magazine en ligne avec des articles de fond très pertinents, alors que nous nous demandons encore où est passé le porteur qui avait lancé l’idée mais qui n’est jamais venu…

Des optimistes pragmatiques – qui s’engagent à résoudre de vrais problèmes à travers une méthode d’accompagnement ascendante et itérative.

Des artisans de l’open source – qui veulent que les progrès des uns puissent être réutilisés pour faire avancer les autres. Tout contenu produit au sein des projets (code, visuels, documentation, etc.) est publié sous une licence libre.

Des hackers indépendants – qui ont choisi d’être 100% bénévoles pour conserver toute liberté dans leur prise de décisions.

Un collectif de bâtisseurs – qui ont conscience que la technologie n’est pas la réponse à tout, mais qui veulent construire brique par brique le monde de demain.

D’après le site de Data for Good

L’équipe de La Data en Clair reflète parfaitement la première valeur de Data for Good : être des faiseurs, plutôt que des parleurs. Au lieu de dire aux autres ce qu’il faudrait faire, nous retroussons nos manches et nous mettons la main à la pâte !

L’exécution prime toujours sur la stratégie, car à quoi bon avoir des idées si elles ne concrétisent jamais ? Cela ne veut pas dire qu’il ne faut pas avoir de plan et courir dans tous les sens, non. Mais cela signifie que les seuls qui ont la légitimité pour établir une stratégie sont ceux qui vont devoir l’appliquer ensuite. Car si les stratèges ne sont pas sur le terrain avec nous pour appliquer ce qu’ils prêchent, nous tracerons notre propre route, comme cette équipe de bénévoles de Data for Good.

Article publié à l’origine sur Medium.

Le produit est la responsabilité de tous

« Ha non, ce n’est pas dans ma fiche de poste… »

Dans les organisations industrielles, chaque travailleur a une série de tâches assignées qu’il doit réaliser d’une certaine manière. Certaines de ces tâches nécessitent d’être spécialiste d’un domaine et sont donc réservées à un groupe restreint. S’agissant de domaines très techniques, il semble normal que l’expertise soit indispensable. Cependant pour d’autres sujets, travailler au sein de groupes composés d’acteurs variés (et concernés) s’avère plus productif.

Lors de la création de services numériques au sein des incubateurs publics, nous pourrions être tentés de ne faire travailler les membres de l’équipe que dans leurs spécialités respectives. L’intrapreneur qui apporte ses connaissances métiers, le designer qui réalise les maquettes, le product owner qui suit le backlog et le développeur qui code.

Nous avons choisi une autre voie. Certes, chacun reste un spécialiste dans son champ d’expertise et nous ne demandons pas aux intrapreneurs d’apprendre à développer. Mais en ce qui concerne le produit, tout le monde participe à la prise de décision et est impliqué.

Le produit est l’élément transverse, la raison d’être des startups d’État et tous les membres de l’équipe doivent savoir que c’est leur produit, dont ils ont la responsabilité, et pas la réponse à une cahier des charges rédigé par je-ne-sais-qui.

À titre d’illustration, lorsque le produit développé par la startup d’État « e-Chauffeur » (une sorte d’Uber disponible pour les trajets professionnels) est déployé dans une nouvelle base militaire, il y a toujours soit un développeur, soit un designer, soit un product owner qui se rend sur place. Rien de tel pour comprendre réellement les besoins des utilisateurs et s’assurer que tout fonctionne.

Comme d’habitude, l’autonomie et la responsabilisation (= skin in the game) plutôt que le micro-management et la sous-traitance.

Article publié à l’origine sur Medium.

Si vous n’avez pas honte, c’est sorti trop tard

« Real artists ship » (Steve Jobs)

Une idée popularisée dans le livre « Lean Startup » d’Eric Ries est que lors de la création de services numériques, il est indispensable de sortir les premières versions le plus tôt possible. Tellement tôt même que nous devrions en avoir un peu honte. C’est tout cela que sous-entend le terme « produit minimum viable », la notion de « minimum » étant évidemment variable selon le contexte et dépendante du degré de finition (ou plutôt de non-finition) que nos utilisateurs sont prêts à accepter.

Avoir honte n’est évidemment pas l’objectif recherché. Nous voulons seulement être capable de tester le plus rapidement possible et en conditions réelles les hypothèses que nous avons émises. Car plus tôt nous confrontons nos produits aux utilisateurs, plus le coût des changements est limité. Cela nous permet donc de faire des erreurs dont l’impact est limité et de pivoter rapidement.

Dans l’administration, ce n’est clairement pas la culture dominante (pour le moment 😉). La méthode classique est de recueillir les besoins exhaustivement, de développer sans rien oublier (lol) et de mettre en production le logiciel une fois que toutes les technologies ont changé et que les besoins ont évolué (moins lol).

Quand nous arrivons avec les premières versions de nos applications, développées en deux mois et dont seulement trois fonctionnalités marchent, il faut faire preuve de pédagogie. Nos utilisateurs ne sont pas habitués à ce genre de méthode et leur indulgence est assez limitée. Nous leur expliquons que le produit est en cours de développement, que tout est loin d’être parfait, mais que nous venons justement les voir pour construire avec eux le service idéal. À partir de là, le niveau d’indulgence augmente et la plupart les agents sont ravis de se savoir impliqués.

Un atelier avec les utilisateurs et une mise à jour de l’application ne sont bien sûr pas suffisants. Ce processus doit être continu tout au long de la vie du service numérique : nouvelle version, retour des utilisateurs, on rince et on recommence. Avec à chaque fois le sentiment que nous aurions pu attendre encore et mieux faire. Mais avec la certitude que le moment était parfait et que le mieux est l’ennemi du bien.

Article publié à l’origine sur Medium.

Faire un pays et pisser du code

« J’ai fait l’Argentine, c’était in-croy-able ! »

Souvent mes amis me disent qu’ils ont « fait » un pays. À chaque fois que j’entends cela, je pense à ces cartes du monde où les pays sont à gratter comme des tickets de loterie. Le but est de se rendre dans chaque pays afin de pouvoir gratter la forme correspondante, pour afficher ensuite à ses invités son caractère aventurier.

Tellement de verbe plus jolis existent pour décrire le fait d’aller dans un pays étranger : visiter, découvrir, rencontrer, flâner, effleurer… Mais ce verbe « faire » décrit bien la touristification du monde, en cours depuis des décennies. Nous voulons en avoir pour notre argent, visiter en une semaine tous les sites incontournables et surtout avoir des photos instagramables. Le tourisme est devenu une industrie comme une autre.

Une autre voie se dessine cependant et quelques signaux faibles apparaissent : des Suédois qui commencent à juger honteux de prendre l’avion, des collectivités qui essaient de faire rester les touristes afin que ces derniers ne visitent pas seulement l’attraction principale. Avec le slow tourism, nous assistons à l’émergence d’une forme de voyage plus artisanale.

Dans le milieu du développement logiciel, ces mêmes grandes tendances coexistent. D’un côté, les SSII embauchent des débutants pour « pisser du code », de l’autre, des coopératives se montent où des codeuses et codeurs tentent de promouvoir l’artisanat logiciel (software craftmanship). Avec évidemment toutes les nuances possibles et imaginables entre ces deux extrêmes.

Comme d’habitude, nos cultures vivent ce phénomène d’oscillations, de cycles. Une fois le monde industrialisé et processé, tout repart dans l’autre sens en faisant de l’artisanalité, de l’unicité, du défaut, bref, de l’humanité, des vertus. Mais au cours de ces oscillations de cultures, les choses ne reviennent jamais telles qu’elles étaient à leur point de départ et tout évolue. Nous sommes sur une trajectoire hélicoïdal plutôt qu’un cercle. Et nous flânons dans ce monde toujours changeant.

Article publié à l’origine sur Medium.

Quand s’arrête l’innovation ?

« La mauvaise nouvelle, c’est que vous êtes en train de tomber dans le vide, Il n’y a rien à quoi vous raccrocher, pas de parachute. La bonne nouvelle, c’est qu’il n’y a pas de sol. » (Chögyam Trungpa)

Que ce soit au sein de l’incubateur de services numériques ou dans chacune de nos startups d’État, nous ressentons souvent cette impression de tomber sans parachute.

Au lancement de nos projets, nous partons avec une bonne compréhension des problèmes que nous souhaitons résoudre et une vision claire de ce qui pourrait exister dans un monde idéal. Cependant la manière d’y parvenir reste souvent floue. Nous construisons le plus rapidement possible des produits minimum viables pour vérifier que nos intuitions étaient les bonnes, afin de limiter les risques pris. Mais à chaque instant, de nouveaux problèmes jaillissent.

Comment recruter les bonnes personnes ? Où vont atterrir nos startups ? Comment concilier agilité et sécurité ? De quelle manière s’insérer dans l’organisation existante tout en gardant des espaces de liberté ? Dès que nous commençons à trouver les réponses à une des questions que nous nous posons, dix nouvelles surgissent. À chaque fois que nous pensons avoir compris, le sol se dérobe, la branche casse, nous perdons pied. Mais la bonne nouvelle, c’est qu’il n’y a pas de sol, pas d’endroit où tomber, pas de fond. Il restera toujours des choses à comprendre et à améliorer.

Les organisations, les cultures et les technologies ne sont jamais figées. Elles sont comme des organismes vivants, ou plutôt comme des espèces qui évoluent sans cesse, grâce à la mortalité des individus. Ce que nous apprenons est utile sur le moment, mais sert surtout à préparer le futur, afin que celles et ceux qui reprendront le flambeau après nous n’aient pas à commettre les mêmes erreurs.

L’innovation elle-même n’a pas de fin. C’est une manière de penser, où rien n’est jamais figé, plus qu’une méthode à utiliser temporairement, le temps de résoudre les problèmes actuels. Les équipes des entreprises technologiques ne se disent jamais que c’est bon, leur produit est parfait et il ne reste plus qu’à le mettre en maintenance et le confier à un prestataire. Pourquoi le ferions-nous ?

De notre côté, nous continuons de nous transformer sans cesse au sein de l’incubateur et des startups d’État, sans parachute certes, mais à quoi bon puisqu’il n’y a pas de sol.

Article publié à l’origine sur Medium.

La raison pour laquelle nous restons agiles

« Tout le monde a un plan, jusqu’à ce qu’il se prenne un poing dans la tronche » (Mike Tyson)

Considérons le monde autour de nous. Tout change sans cesse : souvent des nuages bloquent les rayons du soleil, parfois des gens naissent et d’autres meurent, régulièrement les saisons se succèdent. C’est la seule constante : tout est inconstant.

Les ingénieurs de leur côté sont habitués à utiliser des hypothèses pour simplifier le monde en prétendant que rien ne change, que tout est stable et uniforme. Et grâce à cela, ils ont rendu tant de choses possibles, comme réchauffer des aliments avec des ondes, faire voler des morceaux de métal de plusieurs tonnes dans le ciel ou éradiquer des maladies plutôt horribles. Pour créer tout cela, pas le choix, il est nécessaire de mettre de côté l’infinie complexité du monde, de se concentrer sur son objet d’étude et d’avoir un plan bien défini.

Jusqu’ici tout va bien. Le petit hic, c’est que dans le domaine du développement avoir un plan bien défini est souvent une plaie car quoi qu’il arrive, à un moment donné, nous allons nous prendre un poing dans la tronche. Que ce soit une fonctionnalité que nous trouvions incroyable mais que les utilisateurs ignorent, un bouton que nous avions tout simplement oublié, il y a toujours du changement, et ces changements peuvent même parfois être majeurs.

Sur notre produit e-Chauffeur, une application à la Uber réservée aux déplacements professionnels des militaires, la première version que nous avons développé était en PWA (en gros, une application mobile utilisable dans un navigateur sans installation préalable). Sauf que sur les PWA, la géolocalisation ne marche pas toujours bien et les notifications sont compliquées à envoyer. Nous sommes donc en train de pivoter et de créer une application native pour résoudre ces problèmes.

« Oui, mais vous auriez pu prévoir cela ! » Non justement. Le fait de commencer par une PWA nous a permis de développer beaucoup plus rapidement et d’avoir une application qui est déjà dans les mains des utilisateurs depuis des mois. Nous avons donc des retours sur ce qui fonctionne et sur ce qu’il reste à améliorer. Et le plus important : ces retours proviennent du terrain, du réel, du concret. Car notre seul plan à nous, c’est de se prendre des poings dans la tronche, et de se relever.

Article publié à l’origine sur Medium.

Ce que la crise de 2008 nous enseigne sur l’innovation

La crise financière de 2008 a coûté quelques milliers de milliards de dollars et fait perdre leurs maisons à des millions de familles états-uniennes. Selon le rapport de la “Financial crisis inquiry commission” cette situation a notamment été causée par des innovations financières, une trop grande prise de risque et un manque d’éthique.

Pour gagner plus d’argent, certaines banques américaines ont en effet trouvé des stratagèmes leur permettant de prêter beaucoup plus d’argent qu’elles n’en avaient. Tout un système néfaste s’est mis en place pour inciter des personnes, incapables de rembourser, à emprunter pour devenir propriétaire.

Grosso modo, des agents immobiliers surévaluent le prix des biens (pour augmenter leurs marges), des courtiers font la chasse aux emprunteurs en fermant les yeux sur leur capacité de remboursement (pour toucher leurs commissions) et les banques s’empressent de repackager les prêts (pour les revendre dans le monde entier), avec la complicité des agences de notation qui donnent les meilleures notes (la fameuse AAA) à ces produits financiers pourtant bien pourris. Et quand les défaillances des emprunteurs augmentent et que la valeur des biens commence à chuter, tout s’emballe…

En tant qu’innovateurs et innovatrices, il y a deux leçons que nous pouvons tirer de ces événements :

1/ Le problème majeur de tout ce système est l’asymétrie dont bénéficient tous ces preneurs de risques. Les institutions financières qui ont été renflouées ont pu verser des bonus d’un montant record. Le président de la réserve fédérale de l’époque a fini consultant au lieu de croupir en prison.

Pour tous ces acteurs, soit leurs paris marchent et ils emportent les gains, soit leur paris échouent… et ils empochent quand même des gains. Un système vertueux est basé sur la symétrie : de grands gains potentiels devraient aller de pair avec de grandes pertes potentielles. Car cette symétrie limite naturellement les risques que chacun est prêt à prendre (et donc à faire prendre à l’ensemble de la société).

2/ L’innovation en soi n’est pas forcément porteuse de progrès pour la société. Les instruments financiers utilisés dans cette histoire étaient tous très innovants : credit default swap, collaterized debt obligations, etc. Des termes qui sonnent compliqués et importants, mais dont les effets ont été ravageurs car ils ont amplifié les effets de la crise.

Pour innover dans l’intérêt général, il faut avoir une mission, dans le privé ou dans le public. Il faut vouloir résoudre les problèmes des autres et surtout ne pas faire aux autres ce que nous ne voudrions pas que l’on nous fasse. Encore une fois, la symétrie.

Article publié à l’origine sur Medium.

“Skin in the game” dans les startups d’État

« Si tu réussis, je te couvrirai d’or, sinon, je te jetterai au crocodile. » (Cléopâtre à Numérobis)

Qui est responsable du projet ? Qui sera couvert d’or si c’est une réussite ou jeté au crocodile si rien n’est livré ?

Dans les administrations les responsabilités des individus sont souvent diluées, notamment à cause de leur taille. De plus, selon le principe de continuité, l’administration doit continuer de fonctionner quoiqu’il arrive. Tout le monde doit donc être facilement remplaçable.

Cela entraîne que personne n’est jamais responsable de rien. Attention, cela ne veut pas dire que les agents ne sont pas impliqués. L’immense majorité prend le service public très à cœur. Mais ils n’ont aucun intérêt à prendre des risques, à s’exposer. Or innover nécessite de prendre des risques, de lancer des projets qui peuvent échouer et nous faire passer pour des cons.

Au sein de nos startups d’État, tous les participants s’engagent personnellement : nos noms et nos têtes sont affichés sur les pages qui présentent nos produits. Pour chaque membre de l’équipe, les inconvénients potentiels sont au moins aussi grands que les bénéfices possibles. Ils jouent donc leur peau, skin in the game comme dirait Nassim Nicholas Taleb.

Pour les intrapreneurs, le risque c’est l’image : si le projet rate, ils seront mal vus. Et si tout fonctionne, leur seul gain sera également de l’image. Pas de prime, pas de gain financier, mais la fierté du travail bien fait.

Les freelances qui travaillent au sein des startups d’État sont par nature des gens qui mettent leur peau en jeu, de par leur statut d’indépendant. Du côté de l’incubateur, ils sont considérés comme des membres de l’équipe à part entière, et surtout pas comme des prestataires avec lesquels nous aurions une relation client-fournisseur.

Afin que tout cela fonctionne un maître mot : l’autonomie. Chaque équipe s’organise comme elle le souhaite, utilise sa méthode agile préférée et choisit même ses technologies. Nous n’avons aucun dogme dans le fonctionnement des équipes, car ceux qui créent savent mieux que quiconque ce dont ils ont besoin.

L’or et des crocodiles sont encore loin et ne sont sans doute pas nécessaires. Mais rendre les équipes autonomes et responsables de leur projet est certainement le seul moyen pour que tout le monde se sente impliqué sur le long terme et que nous arrivions à construire efficacement des projets pharaoniques.

Article publié à l’origine sur Medium.

Des théories du complot invasives

En 1859, un britannique importe des lapins en Australie pour le lol et parce qu’il aimait bien chasser. Sauf que des lapins se sont échappés et qu’en l’absence de prédateurs, il y en avait 600 millions sur le continent cinquante ans plus tard. Moins lol.

Les lapins en Australie sont une espèce qualifiée d’invasive : ils ont été parachutés dans un environnement dans lequel ils sont en quelque sorte trop bien adaptés. L’évolution n’a pas le temps de faire son lent travail de régulation et tout un écosystème se retrouve déséquilibré.

Si les mèmes se propagent grâce aux idées comme les gènes à travers les êtres vivants, peut-être existe-il également des idées invasives ? Des concepts qui se retrouvent un jour trop bien adaptés, pas parce qu’ils ont évolué mais parce qu’un nouvel environnement est apparu brutalement, dans lequel ils n’ont aucun prédateur.

Les théories du complot ont sans doute existé depuis des millénaires, évoluant tranquillement par le bouche à oreille, puis par des moyens de communication locaux. Sauf que depuis quelques années ces théories se propagent beaucoup plus vite et auprès de beaucoup plus de monde. Nous avons, avec internet, construit sans le vouloir un environnement trop favorable à leur propagation, perturbant ainsi notre écosystème informationnelle.

En quoi l’environnement actuel est-il propice aux théories du complot ? À cause de la manière dont sont construits les algorithmes de recommandation des réseaux sociaux comme Facebook ou YouTube. Pour ces algorithmes, un bon contenu est un contenu qui fait rester longtemps les utilisateurs sur le site. Comme les contenus complotistes ont tendance à rendre certaines personnes accros et à leur faire passer du temps sur ces plateformes, ils sont recommandés massivement par les algorithmes.

Pour essayer de résoudre le problème des lapins, les autorités ont d’abord tenté d’ériger des barrières pour stopper leur propagation. Puis elles ont introduit des renards qui n’ont fait qu’empirer la situation. Elles leur ont enfin inoculé la myxomatose et plus récemment la maladie hémorragique du lapin, avec plus de succès (côté humain, pas côté lapin).

Réparer les écosystèmes est infiniment plus compliqué que les perturber. Espérons que cela se passe mieux concernant les algorithmes qui recommandent des théories du complot.

Article publié à l’origine sur Medium.

La fabministration : une administration qui fabrique

Dans la fonction publique, la majeure partie du développement informatique est sous-traitée. Il paraît que cela coûterait moins cher et que les données seraient mieux protégées. Je doute qu’Hertz ou la gendarmerie nationale soient de cet avis. Un autre argument qui revient souvent est que ce n’est pas notre cœur de métier de développer des logiciels. Quel est notre cœur de métier alors ? Passer des marchés et écrire des contrats ? La fonction publique serait-elle un cabinet d’avocat ? (no offence aux amis juristes, vous nous sauvez souvent la mise)

Sauf que le numérique n’est pas une fonction support. Est-ce que Facebook sous-traite le développement de ses applications ? Est-ce qu’Amazon considère qu’elle n’est qu’une entreprise de logistique ? Bien sûr que non. Les entreprises qui montent à l’heure actuelle sont celles qui mettent la technologie au cœur de leurs activités. Évidemment, c’est plus facile pour elles en étant nées à l’ère de l’écran et pas à l’ère du papier.

Le but n’est pas forcément de tout développer en interne. Ce n’est peut-être pas le rôle d’un état de créer sa messagerie ou son propre système d’exploitation from scratch (quoique). Mais développer ou adapter des logiciels open source réutilisables par tous semble être une bonne idée. Et cela ne peux se faire qu’en interne : j’attends toujours de voir du code public open source réalisé par un sous traitant.

Comme toutes les administrations ont des besoins similaires, le fait de développer des logiciels open source permet à chacune de réutiliser ce que font les autres. Une des applications réalisées dans notre incubateur, Civils de la Défense, est par exemple installable depuis notre dépôt public, ou disponible en SaaS pour les administrations qui préfèrent la simplicité.

Développer soi-même ses applications permet en outre de commencer petit, d’explorer, de faire des erreurs. Pas d’obligation d’écrire à l’avance toutes les fonctionnalités désirées dans un cahier des charges et de tout contractualiser.

Mais pour fabriquer des logiciels en interne, il faut des gens : profiter des forces présentes en interne, former celles et ceux qui veulent apprendre, voire recruter des personnes de l’extérieur. L’appui des départements RH est donc indispensable. Heureusement, ce métier là n’est pas sous traité !

Article publié à l’origine sur Medium.

Rester humain, même au travail

Le terme de dominant design signifie qu’à un instant et dans une culture donnés, il existe une représentation dominante d’un concept, un standard qui s’impose de lui-même. Au mot « voiture », vous associez sans doute une carcasse métallique posées sur quatre roues en caoutchouc et du gaz qui sort du pot d’échappement. Même si les voitures ont pendant longtemps été de grosses boîtes en bois tractées par des chevaux.

De la même manière, il existe un dominant design sur la manière dont nous sommes censés nous comporter au travail. Cette culture dominante, c’est mettre de côté tout ce qui nous rend humain. Éviter les contacts physiques, cacher nos émotions, remplir des tableaux de reporting. Ne pas dire de gros mots, se désinfecter les mains. Bref, retirer la vie.

Cette culture, c’est surtout celle des grosses structures, privés comme publiques. En effet, quand une entité dépasse une certaine taille, son souci majeur est d’optimiser ses processus, d’être de plus en plus productive et donc de moins en moins créative. L’industrialisation quoi.

Heureusement, la vie trouve toujours un chemin et des instants surgissent durant lesquels les gens osent être eux-mêmes. Une cheffe lance une blague au début d’une réunion très formelle, une bonne relation se crée avec un collègue et tout le monde finit par boire un coup ensemble. L’humain reprend le dessus.

Cette humanité a été pendant des millénaires le dominant design : les gens étaient les mêmes chez eux et au travail. Tout le monde se connaissait, se voyait, tout était artisanal et original. Aujourd’hui les grandes organisations savent qu’elles ont besoin de créativité et d’innovation. Mais cela ne se fera pas sans des espaces et des communautés où être soi-même va de soi. Jusqu’à ce que cette culture redevienne à nouveau la norme.

Article publié à l’origine sur Medium.

Le fond et la forme ; le papier et l’écran

Quand un texte est imprimé sur du papier, c’est pour y rester. C’est d’ailleurs assez agréable d’ouvrir un livre de notre bibliothèque et de constater que son contenu n’a pas changé par rapport à nos souvenirs.

Quand un texte est enregistré sur un ordinateur par contre, il reste toujours modifiable. Certes, ils existent des moyens complexes pour essayer de bloquer ces modifications, mais ce n’est pas « naturel ». Tout sur un ordinateur est censé être variable.

Les écrans sont faits pour le mouvement, avec leurs pixels qui changent de couleur sans cesse, là où les gouttes d’encre sont fixées sur le papier à tout jamais. Cela ne veut pas dire que le monde du papier est mieux que le monde de l’écran. Simplement, ces deux médias n’ont pas les mêmes propriétés et devraient être utilisés différemment. Mais comme le papier est apparu bien avant, certaines utilisations de l’écran sont seulement des transpositions d’un univers à l’autre et ne prennent pas en compte les différences entre les deux.

Dans le monde du papier, le fond et la forme ne font qu’un. Quand nous écrivons sur une feuille, nous choisissons simultanément nos mots, mais aussi la manière dont ils s’agencent dans l’espace. La forme des lettres, l’espacement entre les mots ou la largeur des marges découlent de nos choix (souvent implicites).

Dans le monde de l’écran, le fond peut être complètement séparé de la forme. Même si cela n’est pas forcément visible pour ceux qui n’utilisent que des logiciels de traitement de texte, les développeurs eux sont habitués à écrire le code de cette manière. En langage HTML par exemple, des balises permettent de signaler le rôle d’un élément, comme l’importance d’un mot :

Le dernier mot de cette phrase est en <strong>important</strong>.

Cette dissociation entre le fond et la forme des documents est tellement puissante. Dans une administration qui produit des rapports (les administrations qui produisent des rapports, levez la main 🖐️), il est possible à partir d’un seul document de produire un rapport papier, un rapport internet et un rapport pour les archives. Si une modification du fond est nécessaire, la correction d’une faute d’orthographe par exemple, elle peut être répercutée sur toutes les différentes versions. Si une nouvelle charte graphique est mise en place, tous les anciens rapports peuvent être mis à jour très simplement.

Ce passage du papier à l’écran est un changement de paradigme, qui nous fait passer d’inertie par défaut, au mouvement par défaut. À nous maintenant de tout ré-imaginer pour utiliser au mieux les propriétés de métamorphose de l’écran.

Article publié à l’origine sur Medium.

Fluidifier l’administration, à l’âge de l’écran

Dans son dernier livre intitulé « Les furtifs », Alain Damasio fait l’éloge du mouvement et de la métamorphose permanente. Ses furtifs sont des créatures qui vivent là où personne ne regarde, qui évoluent, s’adaptent et se transforment sans cesse (c’est pas du divulgâchis, tout ça c’est dans l’incipit).

L’administration semble être à l’antithèse de cette philosophie du changement permanent. Et pourtant, un de ses grands principes est la mutabilité, c’est-à-dire le fait que le service public doit s’adapter au monde qui change.

Une des difficultés : la manière dont les agents doivent accomplir leurs tâches est souvent définie explicitement, au lieu de leur laisser de l’autonomie et qu’ils se concentrent sur l’objectif de leur mission. Pire encore, ces contraintes sont généralement écrites sur du papier. Or le monde du papier est prévu pour la conservation, contrairement au monde de l’écran, lui construit pour le changement perpétuel. Les pixels de nos ordinateurs et téléphones s’allument et s’éteignent chaque seconde, alors que les livres restent les mêmes (et tant mieux d’ailleurs).

Pour que l’administration puisse se modifier et changer de forme sans cesse, tout en continuant d’assurer encore et toujours ses missions de service public, deux bonnes pratiques du développement logiciel me semblent inspirantes :

1/ La modularité. Quand du code informatique est modulaire, chaque module remplit une fonction, en recevant des données en entrée et en fournissant un résultat en sortie. Modifier le fonctionnement interne d’un module ne pose aucun problème et n’impacte pas le fonctionnement de l’ensemble, tant que les formats d’entrée et de sortie restent les mêmes.

Or l’administration est souvent organisée en silo plutôt qu’en module, et chaque silo essaye d’optimiser ses indicateurs plutôt que de remplir la mission de l’administration. Pourtant quand les équipes sont autonomes (les modules), se concentrent sur un objectif (la sortie) et s’organisent comme elles le souhaitent, les résultats sont fantastiques. C’est par exemple ainsi que fonctionnent les startups d’État du réseau beta.gouv.fr ou les équipes de l’Agence du numérique, comme Société numérique ou la French Tech.

2/ La documentation. Le code d’un logiciel change sans cesse. Pour s’y retrouver et comprendre qui fait quoi, une bonne documentation est primordiale. Dans l’idéal, cette documentation est facilement explorable et mise à jour à chaque changement de code.

Dans l’administration, il y a tellement de référentiels, de directives, d’arrêtés, de notes, qu’il est souvent impossible de savoir si nous avons bien tout pris en compte. Tout est tellement fragmenté entre différents sites, difficilement explorable et encore plus difficilement modifiable. À l’âge du papier, il était évidemment impossible d’organiser les choses autrement. Mais dans notre âge de l’écran, les référentiels documentaires pourraient être comme le code : disponibles, versionnés et modifiables simplement. Les documents seraient alors comme des furtifs : toujours en mouvement, toujours en vie.

Article publié à l’origine sur Medium.

« Intérêt général » is the new sexy

Il y a quelques semaines, je postais ce tweet pour recruter au sein de ma nouvelle équipe.

Grâce à la magie d’internet (et mes magnifiques emojis), des gens aux profils incroyables ont postulé, des candidats avec une expérience, une motivation et un talent rares. En demandant en entretien la raison pour laquelle ces personnes voulaient travailler au sein de la fonction publique, toutes m’ont répondu « je souhaite avoir plus d’impact » ou « je veux faire quelque chose d’utile ». En résumé, travailler dans l’intérêt général.

Etalab vient d’ailleurs de publier les résultats d’un sondage qui demandait aux geeks ce qui pouvaient les inciter à rejoindre la fonction publique. Résultat : 84 % des répondants veulent « servir l’intérêt général » et 59 % souhaitent « donner du sens à leur travail ». Certes, avec moins de 500 réponses, l’échantillon est faible et pas forcément représentatif.

Cependant cette tendance semble progresser parmi celles et ceux qui travaillent dans le numérique. Du fait de la croissance du secteur, ces experts deviennent plus recherchés et donc plus exigeants. Sans compter le fait que les membres de la génération Y ont maintenant entre 19 et 39 ans et sont connus pour leur quête de sens.

Au sein de Data for Good par exemple, plus de 1400 personnes ont déjà proposé de travailler bénévolement sur des projets numériques au service de l’intérêt général, alors que l’association n’existe que depuis 4 ans et ne fait aucune publicité.

Les startups ont bien compris ce phénomène et sont nombreuses à promettre que leur mission est de « créer un monde meilleur », comme l’a si bien parodié la série Silicon Valley. Or il est parfois difficile de comprendre comment optimiser le nombre de clics sur une publicité améliore le sort de l’espèce humaine.

Au contraire, l’objectif premier de l’État est de faire prévaloir l’intérêt général et les administrations remplissent toutes des missions de service public. Cette finalité change tout quand il s’agit de créer des produits numériques car le but est vraiment d’apporter le meilleur service possible aux utilisateurs.

Au sein de la fonction publique, les équipes des ressources humaines ne s’imaginent pas l’avantage déloyal qu’elles possèdent par rapport au secteur privé.

La transformation numérique est en effet une guerre des talents où il est indispensable de réussir à capter ces profils aux compétences encore rares. Voici donc quelques pistes pouvant être explorées par celles et ceux qui voudraient recruter des geeks d’intérêt général :

1/ Créer une marque employeur. Une marque employeur, c’est d’abord expliquer la mission de l’entité et définir sa raison d’être, plus qu’avoir une belle charte graphique. C’est raconter quelle est notre culture, et annoncer ce qui se fait et ce qui ne se fait pas. Quand beta.gouv.fr tweete pour recruter un développeur ou un designer, toute une communauté d’alliés partage l’information, parce qu’ils connaissent l’état d’esprit de la maison et s’y retrouvent.

2/ Proposer des salaires proches du marché. Les candidats qui souhaitent rentrer dans la fonction publique le font pour le sens. Une partie d’entre eux est même prête à diminuer ses revenus en échange d’une mission plus épanouissante. Mais recruter des experts coûte quand même cher, et les règles de l’administration sont parfois vieux jeu, liant par exemple la possession d’un diplôme à la rémunération. Les choses semblent néanmoins évoluer dans le bon sens, avec par exemple une nouvelle grille de salaires (même si elle oublie les designers).

3/ Impliquer les équipes finales. Si l’équipe qui va intégrer les nouvelles recrues participe à la rédaction des offres, aux entretiens, aux négociations, les candidats vont comprendre qu’ici il n’y a pas que de la bureaucratie et des formulaires à remplir. Il y a des tripes, du cœur, de l’humain quoi. Dans une société où tout s’industrialise, sentir que nous parlons à un congénère et pas à un robot est un sentiment inimitable mais de plus en plus rare. D’où l’importance des emojis 🤗

Article publié à l’origine sur Medium.

Trouver la bonne distance pour un département d'innovation

« Première vitesse cosmique : vitesse minimale qu’il faut communiquer à un corps, au départ de la Terre, pour le satelliser autour d’elle en orbite basse. » (source : Wikipedia)

Selon la force avec laquelle vous lancez un objet depuis la Terre, trois choses peuvent se produire : soit il retombe sur Terre, soit il part dans l’espace indéfiniment, soit il rentre en orbite. Tout est une question de dosage.

De la même manière, un département d’innovation rattaché à une grande organisation a besoin d’être situé à une distance optimale. Trop loin, il est hors-sol et ses projets ont du mal à être réintégrés une fois sortis de la phase d’incubation. Trop prêt, il est écrasé par le poids de l’organisation mère et ses projets ne peuvent pas être développés avec suffisamment de liberté et perdent donc de leur intérêt.

La bonne distance est celle où le département d’innovation est en orbite autour de la grande organisation. Assez loin pour qu’une culture différente se développe à l’abri des règles établies. Mais suffisamment proche pour que tout le monde se souviennent que nous sommes après tout dans la même équipe et que nous poursuivons les mêmes objectifs.

La recette idéale pour qu’un département d’innovation soit situé à la bonne distance ? Des processus adaptés, des équipes mixtes et un lieu dédié.

1/ Des processus adaptés

Pendant des décennies, l’organisation mère a certainement établi des règlements pour faire ce que font de mieux les grandes organisations de l’ère industrielle : optimiser leur productivité. Ces règlements qui définissent précisément comment chaque chose doit être faite risquent d’étouffer les projets d’innovation. C’est leur rôle.

Le département d’innovation doit donc bénéficier d’une dérogation, si possible explicite et signée par les responsables, afin que ses projets soient développés dans une sorte de bac à sable qui échappe en partie à ces règles strictes. Cependant, il faut aussi prévoir un plan pour que les projets puissent être réintégrés et que les règlements se ré-appliquent, une fois les projets matures.

Pour nos startups d’État, le guide « Agilité et sécurité numérique », co-écrit par l’ANSSI et la DINSIC, nous permet par exemple de prendre en compte la sécurité de manière plus agile. La méthode plus classique, consistant à produire des centaines de pages de documentation, est peut-être adaptée aux systèmes critiques mais pour des applications destinées au grand public, mieux vaut se concentrer sur l’acquisition d’utilisateurs, tout en ayant un plan dès le départ pour renforcer la sécurité au fur et à mesure.

Ces deux méthodes ne sont d’ailleurs pas incompatibles car une fois les projets suffisamment matures, nous repassons sur ce mode plus classique.

2/ Des équipes mixtes

Concernant les ressources humaines, il est fondamental d’avoir une partie de l’équipe qui ne viennent pas de la maison mère afin d’avoir une vision fraîche et naïve, car même avec une dérogation, certaines règles restent ancrées dans notre tête. Ces personnes venant de l’extérieur sont aussi une garantie d’être à l’état de l’art, par rapport à ce qui se fait dans l’univers des startups ou des entreprises technologiques.

Tout aussi important, nous avons besoin de gens de l’intérieur qui connaissent la politique et les rouages de l’organisation, qui possèdent un réseau d’alliés bienveillant. En mélangeant tout ça, le résultat est incroyable !

Les startups d’État sont basées sur ce concept : les équipes sont composées d’un intrapreneur, souvent accompagné d’un adjoint, et d’indépendants recrutés pour l’occasion, des experts de haut niveau (développeur, designer, …) qui connaissent le monde réel. L’équipe permanente de l’incubateur fait prendre cette mayonnaise, et s’implique dans la vie des projets.

Nous évitons par contre les consultants car nous voulons que tout le monde fasse partie de la même équipe et se sente impliqué. Et cela n’est possible qu’avec des intrapreneurs ou des indépendants qui ont leur réputation en jeu #skininthegame.

3/ Un lieu dédié

Même si nous travaillons sur des projets numériques, en tant qu’humain nous avons besoin d’un espace physique pour vivre et travailler. Ici encore, pour qu’un département d’innovation fonctionne, il ne doit être ni trop loin, ni trop près. In medio stat virtus, la vertu est au milieu, comme disent les Anciens.

Il faut donc un lieu dédié, séparé physiquement de l’organisation, afin de pouvoir y bâtir une nouvelle culture. Cependant ce lieu doit être géographiquement proche, pour garder une connexion forte et pour que les échanges soient aisés.

Encore une fois, nous sommes gâtés : nos locaux sont à 10 minutes à pied de notre base, nous avons du Wi-Fi rapide, du bon café et un baby-foot (signé par la ministre). Dans les startups, ce genre d’avantages sert surtout à faire rester les salariés plus longtemps le soir sans les payer plus.

Dans une administration, cela peut paraître futile et inadapté, surtout par rapport aux conditions de travail pas toujours évidentes d’autres agents. Seulement ce genre de dispositif envoie un signal fort pour dire qu’ici nous faisons les choses différemment. Et c’est cela le réel objectif d’un département d’innovation : créer un nouvelle culture, par l’exemple.

Article publié à l’origine sur Medium.

Aucun projet ne devrait être immortel

En tant qu’innovateur public, vous avez forcément déjà rencontré cette situation : une personne a identifié un irritant au sein de votre administration et propose une solution numérique pour le résoudre. Comme d’habitude, vous proposez de commencer petit, montrer que vous apportez de la valeur avant de faire grossir le projet pour résoudre d’autres irritants. Pas con.

À ce moment-là, quelqu’un vous lance :

« Pas la peine de lancer votre petit projet ! On a déjà lancé le projet [insérez un acronyme illisible, un prénom féminin ou une référence mythologique] qui fait tout ça, et bien plus encore ! On ne va quand même pas faire deux fois la même chose. »

Cela peut paraître louable de ne pas vouloir créer de doublons. C’est une utilisation vertueuse des deniers publics, comme dirait la Cour des comptes. Sauf qu’il est plus sain d’avoir des projets en doublons, sous réserve que les projets puissent mourir aussi (voire plus) facilement qu’ils ont été lancés.

Pourquoi ? Parce que : le darwinisme. Dans une espèce, les individus les moins adaptés à l’environnement disparaissent avant de transmettre leurs gènes et les plus adaptés survivent. Cela devrait être la même chose pour les projets informatiques : il doivent être mortels, sinon les moins aptes survivent également et placent la barre de plus en plus bas.

Dans un environnement imprévisible (comme l’est le monde réel), avoir plusieurs projets avec des fonctionnalités similaires est une bonne chose, sous réserve qu’on interrompe les projets les moins bons. Mais à cause du sunk cost fallacy, on a tendance à continuer à mettre de l’argent dans un projet qui coule pour essayer de le sauver plutôt que d’arrêter les frais le plus rapidement possible.

C’est pour ça que le modèle des startups d’État est si intéressant : en commençant petit et pas cher, on a moins mal au coeur quand il faut tuer un projet qui ne marche pas.

Nos projets sont donc mortels, CQFD.

Article publié à l’origine sur Medium.

Design d’État : design éthique ?

Nouveau message : « Cliquez ici pour lire le message que vous avez reçu. »

Toutes les entreprises tech affirment créer des produits « centrés sur les utilisateurs ». Toutefois la manière dont sont conçues certaines fonctionnalités pourrait nous en faire douter. Les plateformes internet spécialisées dans le business de l’attention envoient par exemple des courriels pour nous signaler que nous avons reçu un nouveau message, sans afficher le message en question.

Si le design était vraiment centré sur l’utilisateur, pourquoi ne pourrions-nous pas lire immédiatement le message, voire répondre directement par courriel ? Personne n’est dupe : l’objectif est de nous faire passer du temps sur la plateforme car le produit n’est pas vraiment centré sur l’utilisateur, mais plutôt sur celui qui achète l’espace publicitaire.

Les services numériques créés par les administrations n’ont pas cette contrainte. Du point de vue du service public : un bon site web est un site où le citoyen reste le moins longtemps possible, parce qu’il a réussi à effectuer rapidement sa démarche ou à trouver facilement l’information qu’il cherchait. L’État est donc un des rares endroits où il est vraiment possible de faire du design centré sur l’humain, car les intérêts des administrations et des citoyens sont parfaitement alignés. En tout cas en théorie…

Dans les faits, tout n’est pas si simple car la culture « produit » est encore balbutiante au sein de l’État. Et pour cause, mesurer l’efficacité d’un produit dans une entreprise est assez simple : il suffit de regarder ce qu’il rapporte par rapport à ce qu’il coûte. Mais dans l’administration, comment savoir si un design est bon ou pas ? La seule manière est de se reconcentrer sur les missions : pourquoi faisons-nous ce service numérique ?

Dans nos startups d’État, nous nous efforçons de revenir sans cesse à ces missions. Pour notre plateforme de recrutement, nous mesurons combien de personnes ont été embauchées via ce canal. Pour notre application de transport avec chauffeur, nous comptons combien de courses sont réalisées chaque jour. Si ces chiffres augmentent, c’est que nous sommes dans la bonne direction.

Cela paraît tellement simple une fois écrit dans un article. Mais combien d’applications étatiques ont des indicateurs qui correspondent à la mission de l’administration ? Combien n’ont même pas d’indicateurs ?

L’État a donc besoin de designers pour continuer à transformer sa culture interne, afin d’imaginer des services réellement centrés sur nous, les humains. Et pour les designers, il s’agit d’une opportunité unique de vraiment faire du design éthique. Rejoignez-nous !

Article publié à l’origine sur Medium.

Des chevaux plus rapides

« Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides. » (citation apocryphe d’Henry Ford à propos de la Ford T)

Lorsque nous développons une solution numérique censée résoudre un problème administratif sans changer les processus, le risque est grand de réintroduire les lourdeurs que nous souhaitions supprimer. La transformation numérique, ce n’est pas passer d’un CERFA papier à un CERFA pdf ! C’est une opportunité de prendre du recul afin de se demander quel est vraiment l’objectif de ce que nous faisons.

Prenons l’exemple de la startup d’État « Civils de la Défense ». Elle a été lancée pour répondre à ce problème très concret : comment recruter des milliers de personnes par an, notamment sur des métiers sous tension ? L’équipe aurait très bien pu reproduire la procédure actuelle en la numérisant, générant seulement une nouvelle surcouche numérique. Au lieu de cela, elle en a profité pour s’interroger sur ce qui pouvait simplifier un recrutement : cette direction doit-elle nécessairement tout valider ? Ce service doit-il contrôler à priori toutes les offres postées ? En procédant ainsi, elle a développé un outil numérique qui non seulement simplifie la vie des utilisateurs, mais aussi transforme l’organisation en enlevant des étapes superflues.

La transformation numérique est l’occasion rêvée de repenser nos manières de travailler. C’est pour cela qu’il est si fondamental de se concentrer sur le problème à résoudre, et pas sur la solution que nous avions en tête. C’est pour cela qu’il faut éviter les indicateurs qui font du bien à l’ego et se concentrer sur la mesure de l’impact. Car l’objectif est d’améliorer la vie des gens, pas de créer des chevaux plus rapides.

Article publié à l’origine sur Medium.

Trouver un problème avant de chercher une solution

« On veut faire un projet basé sur de la blockchain. — Super ! Et vous essayez de résoudre quel problème ? — On n’est pas encore sûrs, mais on veut qu’il y ait de la blockchain. »

Certaines innovations deviennent en quelques années très connues du grand public. Tout le monde veut alors son projet basé sur telle ou telle technologie. C’est normal : il est plus simple de communiquer dessus car chacun sait de quoi il s’agit. Il est plus facile d’aller voir sa cheffe et d’obtenir un budget. Cela peut également refléter une décision stratégique prise à haut niveau : les organisations ont parfois peur de passer à côté de quelque chose que leurs concurrents pourraient avoir et d’être laissées sur le carreau.

Ce phénomène existe aussi bien dans les startups que dans les grands groupes, les administrations, ou les associations : il faut être le premier à faire de l’IA, de la réalité virtuelle, de l’IoT… Certes, il y a un effet fédérateur à utiliser des technologies de pointe. Cela inspire les équipes, facilite le recrutement, renvoie une image de modernité. Mais c’est mettre la charrue avant les bœufs. Avant de sélectionner une technologie, il est indispensable d’avoir une vision claire du problème que nous essayons de résoudre. Aucun bricoleur ne s’est jamais dit : « Je viens d’acheter cette perceuse dernier cri, comment vais-je pouvoir poser mon carrelage avec ? ».

Les projets innovants qui réussissent sont ceux qui utilisent la technologie comme un moyen et pas comme une fin. Ce sont ceux qui tentent de résoudre un problème, de diminuer un irritant, d’apporter de la valeur. Ce sont ceux où des designers vont sur le terrain écouter les humains qui vont utiliser le produit. Car la technologie est un esclave utile mais un maître dangereux.

Article publié à l’origine sur Medium.

Inertie et administration : it’s not a bug, it’s a feature

Imaginez un énorme vaisseau spatial, un des croiseurs interstellaires de Star Wars par exemple. Imaginez ce vaisseau lancé dans le vide sidéral, à plusieurs milliers kilomètres par heure. Seriez-vous capable lui faire changer sa course en vous mettant devant ?

Quand on essaie de transformer l’administration de l’intérieur, on a parfois l’impression de se retrouver face à un vaisseau spatial inarrêtable. Sauf que cette inertie est la principale force de l’administration. C’est un système tellement résilient, qu’il est capable de survivre à des changements de gouvernement, à des catastrophes naturelles, voire à des guerres. À l’heure où toutes les startups ne parlent que de croissance exponentielle et de momentum, qu’est-ce qu’une administration, sinon une startup qui a réussi ?

C’était le conseil que je donnais cet après-midi aux entrepreneurs d’intérêt général de la 3ème promotion, sur le point de commencer leurs missions : quand on entre dans l’administration, on monte à bord d’un immense vaisseau, qui ne nous a pas attendu pour avancer et qui continuera sa course bien après nous. Donc si nous voulons modifier même très légèrement sa trajectoire, il va falloir y mettre beaucoup d’énergie. Ce n’est pas pour rien si le nom du programme commence par « entrepreneur » : c’est parce que personne ne viendra nous chercher par la main pour changer les choses.

Article publié à l’origine sur Medium.

L’État plateforme : un fournisseur de services publics ouverts ?

Alors que 9,3 milliards d’euros du Grand plan d’investissement (GPI) du gouvernement sont consacrés à la numérisation de l’administration, l’association Free Software Foundation Europe démarre une campagne intitulée « Public Money, Public Code ». Son objectif ? Que les logiciels financés par le contribuable soient publiés sous licence libre. Grâce à ces licences libres, les logiciels peuvent être personnalisés et réutilisés, contrairement aux licences propriétaires habituellement choisies par les administrations qui interdisent toute modification.

Les infrastructures publiques sont en effet censées bénéficier à l’ensemble de la société : les villes font par exemple construire des bibliothèques accessibles à tous. Certes, les plans des bâtiments ne sont pas rendus publics mais l’intérêt serait limité car les infrastructures physiques sont très spécifiques. En revanche, partager les « plans » qui permettent de construire les logiciels (ce qu’on appelle les codes sources) présente de nombreux avantages.

Tirer parti de la multitude

Les logiciels propriétaires sont des boîtes noires dont il est illégal de chercher les failles, comme un contrat inaccessible dont seuls les effets seraient visibles. À l’inverse, les logiciels libres font le pari de la transparence car leur code source est exposé publiquement. Lorsque des développeurs identifient un problème, ils modifient le code source puis le partagent afin que tout le monde bénéficie de la correction. Les plus aguerris peuvent également ajouter les fonctionnalités dont ils ont besoin et les partager.

Les outils numériques publics pourraient ainsi être développés une seule fois et adaptés selon les spécificités, au lieu d’être achetés encore et encore pour des besoins similaires. Un logiciel de paie créé par une administration pourrait être réutilisé par une autre, qui a son tour l’améliorerait et en ferait profiter la multitude. On imagine le gain d’efficacité si cette politique était déployée sur l’ensemble du territoire.

L’ouverture a commencé

La France est déjà avancée sur ces sujets. La mission Etalab, chargée de coordonner la politique open data, a déjà ouvert le code source derrière la plateforme de partage de données data.gouv.fr. Résultat : le Luxembourg l’a reprise pour diffuser ses données publiques et la Cour des comptes est en train de l’adapter pour partager ses données en interne. Si l’État est loin de publier tous ses logiciels en licence libre, des initiatives encourageantes apparaissent comme le ministère de l’Éducation Supérieur qui étudie les conditions d’ouverture du système Admission Post-Bac (APB).

Outre-Manche, l’association mySociety à développé FixMyStreet, un service qui propose aux habitants de déclarer leurs problèmes locaux — trottoirs abîmés, éclairage public défaillant, etc. — afin que leur ville intervienne. Ce logiciel libre est utilisé aujourd’hui dans plus d’une dizaine de pays, mais nécessite à chaque fois des ressources humaines et matérielles pour installer et administrer la plateforme. Ces contraintes freinent les collectivités qui ne disposent pas des moyens nécessaires. Pour que ce genre d’initiative soit diffusé à plus grande échelle, il faut réfléchir à de nouvelles stratégies de déploiement.

Vers un État plateforme

Une solution est de proposer des « logiciels en tant que service », aussi appelés SaaS pour Software as as Service. Des services comme Google Mail ou Hotmail sont des SaaS : inutile d’être expert pour les configurer, il suffit de s’inscrire en ligne pour bénéficier d’une messagerie complètement paramétrée. Les logiciels créés par l’État pourrait suivre la même logique : une administration ayant besoin d’un logiciel de paie ouvrirait un compte sur paie.gouv.fr pour accéder à un service configurable maintenu par le gouvernement. L’infrastructure ne serait gérée que par un seul opérateur, et si par exemple une loi changeait les taux de prélèvements, un seul changement mettrait tout le système à jour.

Ce nouveau paradigme, en plus des économies qu’il génère, a le potentiel de contribuer au rayonnement international de la France en la transformant en fournisseur de services pour les administrations à l’échelle mondiale. Dans une économie numérique basée sur l’abondance, le pouvoir n’est plus dans les mains de ceux qui possèdent le savoir, mais de ceux qui partagent leurs ressources. C’est là l’essence même de la notion d’État plateforme : construire un environnement de partage de logiciels libres et de données ouvertes au service de l’intérêt général. Y parvenir va nécessiter une volonté politique forte plus qu’un plan d’investissement, afin que les toutes les administrations deviennent comme Etalab des créatrices de services publics numériques pour les démocraties de demain.

Article publié à l’origine sur Medium.