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.
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 ?
À 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 :
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 :
Et vous ? ;)
