La semaine dernière a été riche en réunions, rencontres et leçons diverses et variées. Je le savais déjà, mais l’administration, c’est réellement l’enfer. Notez que le problème est globalement le même dans les grandes entreprises.
Tous les gens qui bossent un minimum avec un clavier et un écran le savent, il est très rare de tomber sur un logiciel qui fait exactement ce qu’on veut, quand on veut et de la manière qu’on veut. Pourquoi ? Tout simplement parce que ceux qui font les logiciels sont rarement ceux qui s’en servent.
L’ensemble du dispositif des labs repose sur un outil communautaire aux multiples facettes qui n’existe pas encore (wiki, agenda, base documentaire, forums, blogs…). Comme tout dans l’administration, ce logiciel fait l’objet d’un appel d’offre qui devrait théoriquement être terminé bientôt. On m’a proposé de participer aux réunions avec les entreprises qui y ont répondu avant de me dire « ah ben non, en fait, tu ne peux pas venir ».
Pourquoi je ne peux pas y aller ? Parce que je ne fais pas partie de l’administration. C’est une règle qui n’est pas si idiote que ça, je pourrais par exemple avoir un intérêt financier avec une des entreprise et tenter de la faire passer devant les autres. Mais dans le cas qui nous intéresse, c’est particulièrement idiot, puisque je serai l’un des utilisateur de la plateforme finale et que j’ai d’assez bonnes idées sur les fonctionnalités qu’elle devrait avoir et les outils à mettre en place.
Second paradoxe qui est paru dans la presse la semaine dernière, pour des raisons d’équité entre les candidats, l’administration ne peut pas écrire un appel d’offre disant par exemple « nous avons besoin d’une boite pour installer et héberger un mediawiki et un wordpress sur une infrastructure FreeBSD ». Non non, il faut écrire « nous avons besoin d’un espace collaboratif de type wiki et d’un moteur de blog », libre à chaque candidat de proposer une solution et l’OS qui va avec. Il est manifestement aussi assez difficile aussi d’orienter un prestataire vers un type de solution (libre ou pas, par exemple) plutot qu’un autre, si aucune justification technique ne l’oblige (par exemple « on veut une solution bidule sous windows parce que tous le reste de ce qu’on a en interne est du windows et que ça s’intègrera mieux », ça peut passer. « On veut du logiciel libre parce que c’est bien et qu’on pourra en faire ce qu’on veut après », moins.).
Le cycle ressemble donc à :
- Les utilisateurs expriment leur besoin. Dans le cas qui nous intéresse, ce n’est pas possible, puisqu’ils ne sont pas encore connus, que ce soient les utilisateurs ou les besoins.
- Quelqu’un dans l’administration les compile et constitue un cahier des charges en respectant les règles des marchés publics . Ici, ce sont tout de même des personnes qui ont une bonne idée de ce que doit être le produit final, mais c’est loin d’être toujours le cas.
- Des entreprises répondent à l’appel d’offre en chiffrant le travail, les délais, et en présentant la solution technique et logicielle qu’ils envisagent.
- Un comité se réunit pour décider de quel candidat sera retenu. Dans le cas qui nous intéresse, ce devraient être les mêmes que ceux qui ont constitué l’appel d’offre mais encore une fois, ce n’est pas toujours le cas.
- L’entreprise fait le boulot sous le contrôle de l’administration, mais probablement pas (ou peu) sous celui des utilisateurs finaux.
- Les utilisateurs finissent par obtenir l’outil dont ils ont besoin, passé entre les mains de plusieurs personnes qui ne s’en serviront pas, et font remonter les commentaires/critiques/idées pour une éventuelle seconde version qui mettra plusieurs mois à parcourir le même cycle pour finir par arriver généralement pile au moment où personne n’aura plus aucun besoin des fonctions demandées, puisqu’entre temps, ils auront trouvé une méthode pour contourner le manque et s’y seront habitués.
Imaginez la tête d’un ébéniste qui vous demande de quoi raboter son bois et à qui vous fournissiez un épluche légume, puis un cutter, puis une scie circulaire, alors que lui, il voulait juste un rabot.
De mon coté, mon pragmatisme m’a dicté un commentaire évident « ne serait-il pas plus simple de trouver un prestataire qui n’offrirait que des heures de développement et de déploiement et de lui commander, par la suite, petit à petit, chaque brique dont on a besoin pour constituer l’outil final ? ». Oui, mais ça, il aurait fallu le prévoir dans les budgets et ce n’est globalement pas dans les méthodes appliquées dans les administrations où chaque dépense doit entrer dans une case bien précise. Bien entendu, la case « temps homme pour avancer plus vite », ça n’existe pas.
Ceci dit, à toute chose malheur est bon, et les victimes de ces principes monolithiques déploient généralement des trésors d’ingéniosité pour contourner le problème. La centrale d’achat par laquelle on est obligé de passer pour les commandes de matériel ne dispose pas, dans son catalogue, du dernier modèle de tel ordinateur dont une équipe a besoin pour avancer dans son travail ? Qu’à cela ne tienne, on va l’acheter soi-même avec la carte bancaire de société qui sert normalement à payer le resto aux clients et on fait croire au comptable que c’était une dépense urgente pour remplacement d’un matériel en panne et hors de garantie qui était absolument indispensable au travail d’au moins 40 personnes (vécu chez un de mes clients).
Conclusion : si globalement c’est une bonne idée d’imposer des limites aux dépenses pour ne pas jeter l’argent par les fenêtres, il y a un moment où c’est totalement contre-productif.
Laisser un commentaire