github twitter

Comment céder une Startup d’État ?

Un incubateur de Startups d’État n’a pas vocation à constituer un Système d’Information en lieu et place des équipes habituellement en charge. Il a au contraire vocation à faire pénétrer l’innovation au coeur des organisations et de leurs systèmes d’information.

Au bout d’un à trois ans, une startup incubée aura obtenu à peu de frais la preuve de sa capacité à satisfaire des usagers pilotes, volontaires, voire friands d’innovation. Mais ceux-ci ne représentent souvent que quelques pourcents du potentiel. Or une Startup d’État souhaite moderniser une manière de faire dans toute une administration, la généraliser réclame alors que les moyens humains de l’organisation en charge soient désormais pleinement mobilisés.

Le mariage impossible

Les services construits par des Startups d’État sont le fruit de pratiques souvent très différentes de celles en vigueur dans les directions informatiques des administrations. Équipes produit intégrées au contact direct de l’usager, itérations courtes (livraison d’une nouvelle version toutes les deux semaines) et permanentes (le produit ne cessera de s’améliorer tant qu’il aura des usagers)…

Les DSI des administrations sont quant à elles plus habituées à une séparation des rôles entre maîtrise d’ouvrage, maîtrise d’oeuvre, architecture, sécurité, achats, recette, équipes d’exploitation, gestion du changement, TMA… Cette organisation fonctionne en étapes longues de plusieurs mois structurées par des contrats formels (cahier des charges, spécifications, cahier de recette, dossier de sécurité, cahier d’exploitation…). Une séparation nette est maintenue entre équipes « projet » auxquelles succèdent des équipes « maintenance », là où une Startup d’État ne retient qu’une équipe permanente, à l’affût des améliorations permettant d’améliorer et de diffuser le service.

Transférer un service public numérique d’une petite organisation de culture agile vers une grande organisation de culture contractuelle va donc naturellement provoquer un désir de « retour à la normale » vers le cadre contractuel connu. Mais mettre en risque les pratiques qui ont permis de construire le service, c’est mettre en péril le service lui-même ! Facebook pourrait-il encore être le premier réseau social mondial s’il était en maintenance dans une SSII ?

Éloge de la différence

À la vérité, l’immense majorité des DSI souhaite aujourd’hui intégrer de nouvelles manières de faire, sans toujours trouver le chemin qui leur permette de s’extraire d’habitudes ancrées dans l’organisation.

Accueillir une équipe travaillant autrement est donc une opportunité unique d’initier un tel changement, sans rupture. En effet, rien n’empêche la DSI de fonctionner dans ses habitudes et son organisation classique MOA/MOE/Exploitation, et d’héberger dans le même temps des équipes intégrées, de l’utilisateur à l’exploitant, en passant par le développeur.

Les bénéfices sont triples :

  • continuer à enrichir le produit sans perturber l’organisation intégrée qui a lui a donné vie ;
  • enrichir l’offre de service de la DSI et de la MOA, en proposant un nouveau guichet à ses usagers finaux : l’offre agile ;
  • permettre à d’autres équipes existantes d’envisager de basculer dans ce mode si elles le souhaitent : la présence d’une première équipe agile permet de lever les barrières au changement et d’aider les informaticiens volontaires à faire le pas.

Une passation en douceur

Pour sécuriser une passation de service, nous proposons généralement un schéma fondé sur le volontariat : le DSI lance un appel à vocation pour des opérationnels souhaitant s’investir à la fois dans le service et dans les pratiques : « Vous êtes développeur informatique ou ingénieur système ? Vous souhaitez travailler selon les principes des méthodes agiles dans une équipe DevOps intégrée ? Le champ du [domaine de la Startup], et des technologies comme [outils de la Startup] vous intéresse ? Contactez-nous ! ».

L’incubateur accueille ces personnes pour 3 à 9 mois de travail en binôme avec l’équipe historique de la startup qui l’acculture à ses méthodes : dialogue usager, pilotage par l’impact, itérations fixes, tests automatisés, remaniement de code, rituels d’équipe… Lors de ce passage, nous encourageons les membres de l’équipe historique qui souhaiteraient accompagner le service dans la durée à rejoindre cette nouvelle organisation.

Autour de ce principe général, se brossent des portraits de cessions assez variés selon les contextes :

  • satellisé : PIX est devenu un Groupement d’Intérêt Public (GIP), totalement autonome de son ministère de tutelle. Pourquoi ? Car son activité est indépendante du reste de l’Education Nationale, et n’avait pas d’intérêt à y fusionner.
  • inter-ministériel : quelle administration peut porter un système dédié au décloisonnement de toutes les administrations ? Aucune n’a cette mission ! Alors il a fallu la créer : api.gouv.fr, une mission de la Direction Interministérielle des Systèmes d’Information et de Communication de l’État (DINSIC) qui industrialise par exemple API Entreprise, pour éviter chaque mois aux entreprises la production de 1,3 millions de pièces justificatives.
  • internalisé DSI : à Pôle emploi, le produit MEMO est arrivé à maturité après un an. Mieux, son mariage avec le site institutionnel est en cours : chaque annonce sur Pôle emploi.fr disposera bientôt d’un bouton « Enregistrer dans MEMO », qui permettra au demandeur d’emploi de mieux gérer son portefeuille d’actions en cours, un problème récurrent lors de la recherche d’emploi. Cette plus grande proximité, qui lie notamment la disponibilité du service MEMO à celle de Pole-emploi.fr va contribuer à rapprocher les équipes…

Et vous ? ;)