Skip to content

Instantly share code, notes, and snippets.

@Morendil
Created September 12, 2018 08:18
Show Gist options
  • Save Morendil/11b9c68c2519932a18aaa41777bda012 to your computer and use it in GitHub Desktop.
Save Morendil/11b9c68c2519932a18aaa41777bda012 to your computer and use it in GitHub Desktop.
Quand on m'a demandé fin 2014 d'écrire ma fiche de poste…

L'un des dictons de la nouvelle économie est "culture eats strategy for breakfast": non pas définir une stratégie au sommet, puis l'imposer a la base par le jeu classique de la hiérarchie, mais veiller a partager des valeurs, et laisser chacun les transcrire en actes en s'adaptant aux situations. Le paradoxe, c'est qu'on ne décrète pas un changement culturel: la culture, c'est la somme de ce que l'on fait de façon si habituelle qu'on y réfléchit meme plus. La culture émerge de pratiques, d'invariants de comportement.

On ne décrete pas le recours a la multitude, le changement culturel, la transformation de l'entreprise en plateforme: on en crée les conditions. On peut encourager, protéger, récompenser (sans ostentation) des comportements et des pratiques; vérifier périodiquement leur adéquation aux valeurs. C'est aux individus de faire le reste, c'est-à-dire l'essentiel.

Voici donc un catalogue de pratiques, de comportements, de tactiques: nécessairement provisoire, mais visant à servir de point de départ.

Le "faux départ stratégique": apprivoiser l'échec et se défaire de l'addiction aux gros projets. Donner aux équipes une durée ridiculement courte pour un premier livrable concret, qui puisse être confronté a un public: deux semaines. "If you're not embarrassed by your first release, you waited too long." Un premier livrable doit permettre de tester une hypothèse sur l'adéquation entre service attendu et service rendu, et selon toute vraisemblance, ce premier test sera un échec.

Se confronter systématiquement a la question "qu'avons-nous appris en échouant", tout en minimisant l'investissement. Limiter les projets a quatre ou six mois.

Plonger dans le grand bain de l'open source. Travailler directement sur Github "comme tout le monde". "Le code est la loi" (et inversement les lois deviennent du code), et la loi doit être connue de tous: pourquoi les SI au service du public devraient-ils se soustraire a son regard? Travailler au grand jour peut aussi être un aiguillon pour la qualité, et s'appuyer sur le meilleur des forges logicielles les plus réputées permet d'évacuer nombre de questions d'outillage.

Ne plus faire de l'informatique une excuse. L'expression "un problème technique" doit disparaitre: si l'utilisateur constate une entrave, c'est un problème de management. Quand un système critique soumis a un pic de fréquentation prévisible "tombe" sous la charge, se dédouaner sur l'informatique est une trahison. Se donner les moyens - clouds, tests de charge, etc - pour que les SI deviennent élastiques.

Devops: "you build it, you run it". Gommer les frontières entre les développeurs et les exploitants, dont les relations sont trop souvent semblables à celles entre les Eloi et les Morlocks de H.G. Wells: les uns vivant dans l'insouciance et les autres, dociles dans les profondeurs, leur faisant de temps à autre payer un prix douloureux pour leurs services discrets...

Sortir de son bureau. Cultiver une double pratique de l'expédition de terrain: les développeurs se rendent sur le terrain en allant a la rencontre de leurs utilisateurs, où qu'ils soient. Les managers se rendent sur le terrain en allant au contact des équipes.

S'ouvrir sur l'extérieur. La porosité est une condition nécessaire a l'acquisition de nouvelles competences et nouveaux réflexes. Encourager les développeurs a trainer dans les meetups, les conférences, a partager leurs retours d'expérience. Ouvrir les portes a des intervenants extérieurs.

Se hâter lentement. Favoriser le "slack time", des temps substantiels ou les équipes font ce qu'elles veulent: des conférences ou des non-conférences, open spaces, dojos, brainstorms, hackathons. Ces temps de veille et de prise de recul font partie du travail et du budget de chaque projet, de même que l'amélioration continue qui ne doit pas être sacrifiée à la pression des livraisons.

Valoriser les développeurs. La tache a accomplir est énorme. L'Etat, comme toutes les entreprises, tarde trop a traiter l'accumulation de la dette technique. Pour réussir, c'est un corps d'élite qui est a bâtir, une nouvelle incarnation de l'idéal des "hussards noirs" - et si cet effort doit rappeler douloureusement a quel point d'autres corps, comme les enseignants, se trouvent aujourd'hui dévalorisés, tant mieux.

Changer l'image des développeurs. Les "hussards numériques" ne peuvent pas non plus prendre pour modèles les Zuckerberg et leurs épigones, ce serait désastreux. L'informatique de la Valley est jeuniste, sexiste, parfois raciste, souvent autiste. Celui qui peut résulter d'une transformation citoyenne est a l'écoute des utilisateurs, sensible aux aspects culturels et pas seulement techniques, conscient des défis éthiques et de ses responsabilités.

Se concentrer sur les scénarios d'usage, des "user stories" au sens premier du terme, pas sur les domaines de responsabilité. Traiter "je déménage" plutôt qu'innover par petits bouts et de façon décorréllée dans chacun des systèmes concernés par changement d'adresse.

Aborder les sujets qui fâchent: on voit des mobilisations importantes par exemple sur les déclarations de patrimoine des élus, preuve que ces sujets qui touchent a la moralité de l'action publique font aussi partie des "irritants" majeurs. Ou encore la transparence sur les projets d'équipements - aéroports, retenues d'eau... Cantonner l'innovation a des sujets "sans risque" serait aussi démentir le message.


Se concentrer sur les besoins de l'innovation "programmée" ne suffit pas. Une plateforme réduit les freins qui pèsent sur l'innovation opportuniste. Elle permet a ceux qui ont une bonne idée de la prototyper en 5 minutes, de la tester en 1 journée, de la montrer en 2 semaines. Elle réduit l'écart entre l'idée et l'exécution, entre le penser et le faire.


Des pistes par domaines d'intervention...

Santé

  • le dossier médical personnalisé? déjà lancé, mais pas un modèle

Retraites

  • opacité individuelle: chacun devrait pouvoir connaitre sa pension future
  • opacité collective: on devrait pouvoir calculer/simuler l'effet des mesures

Juridique

  • la signature numérique facile et intégrée, style HelloSign
  • le classeur numérique pour les justificatifs, documents, etc
  • transparence des procédures de justice, dates, charge des tribunaux...

Démarches

  • projets inter-administrations autour des événements de la vie, majorité, mariage, etc
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment