Comparer l’État à une startup, c’est bien séduisant. Une startup part avec 0 client. L’État, lui, doit déjà servir toute la population, avec très peu de marge d’erreur.
Et oui, c’est souvent fucking long et cher.
Quand j’ai lu le texte de Nicolas Duvernois, j’ai compris son réflexe. J’aime ses valeurs entrepreneuriales et son impatience devant les grosses machines qui coûtent trop cher et qui livrent trop lentement. J’ai déjà pensé exactement comme lui, avant de travailler de l’intérieur.
Ce que j’ai compris avec le temps, c’est que l’État n’a pas du tout la liberté qu’on lui prête de l’extérieur.
Une startup part souvent avec une intuition, un produit ou une technologie prometteuse. Elle lance quelque chose dans le marché et regarde si quelqu’un mord. Si le client n’est pas le bon, elle change de cible. Si le modèle ne tient pas, elle pivote. Si une fonction complique trop le produit, elle peut la retirer. Et si rien ne fonctionne, elle peut disparaître.
L’administration publique, c’est l’opposé total. Le gouvernement part avec toute la population déjà à servir, avec des réalités très différentes. Il ne peut pas choisir seulement les cas simples qui l’arrangent. Il ne peut pas écarter les personnes vulnérables parce que leur situation complique le service. Il ne peut pas abandonner une clientèle parce qu’elle coûte trop cher à soutenir.
Il hérite aussi de règles déjà discutées, négociées, amendées et adoptées avant même que le numérique arrive. Une loi, des règlements, des exceptions, des droits acquis et des compromis accumulés avec le temps. Chaque ajout répondait généralement à un besoin réel, mais une fois en place, il devient rarement simple de revenir en arrière.
Quand les équipes informatiques arrivent, une bonne partie de la souplesse a déjà été dépensée. On leur demande ensuite d’être agiles autour d’un besoin qui ne l’est déjà plus vraiment.
Même côté techno, l’État ne repart presque jamais de zéro. Depuis les années 60 et 70, les gouvernements ont bâti des systèmes pour percevoir l’impôt, payer des prestations, gérer des permis et tenir des registres. Ces systèmes ont rendu service longtemps. Ils ont aussi accumulé des couches, des dépendances et des compromis techniques.
Moderniser ça, ce n’est pas construire une application neuve dans un garage. C’est rénover un immeuble occupé pendant que les services continuent.
Ça n’excuse pas les projets mal gouvernés, les coûts difficiles à défendre ni les comités qui ralentissent plus qu’ils ne protègent.
Mais si on veut vraiment faire mieux, il faut viser plus tôt dans la chaîne. Le numérique doit être autour de la table pendant qu’on conçoit les programmes, pas seulement après, quand il faut les livrer. Sinon, on découvre trop tard qu’une mesure simple à annoncer est devenue très lourde à réaliser.
Si on veut faire plus simple, il faut arrêter de croire que le problème commence seulement quand les informaticiens arrivent.