Turb(l)o(g)
Le paradoxe des outils
| Tweet |  |
Crédit photo : Frédéric Bisson
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.
Haha, mon pauvre, je vois que tu découvres toute l’étendue du drame de l’achat public, et la schizophrénie comme mode de fonctionnement au quotidien : « Cher collègue, en tant que praticien des marchés publics, je suis censé vous dire ça, mais comme ça va prendre des mois et que ça va foirer, on a aussi telle solution, tirée par les cheveux, dure à justifier, mais qui marche… ».
“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 ?”
Je lâche le mot tabou : Agilité. Je pense que tu sais très bien que ce que tu décris correspond à quelques une des méthodes de développement agiles.
Pour avoir fait ma deuxième année de Master avec les méthodes agiles, je peux te dire que cette approche n’est pas prête d’arriver en France. En France, la décision est hiérarchique pas technique.
C’est bien dommage parce que dans le cadre de votre élaboration de nouveaux outils, j’ai l’impression que le besoin se définit à : « on veux des outils, beau, simple, pas cher et rapidement ». Ce qui va se traduire en terme de livrable en « buggé, pas utilisé car pas adapté », et aussi peu couteux que soit le livrable, s’il n’est pas utilisé alors il est déjà trop cher.
Quand je vous lis je me dis qu’avant de faire passer vos idée vous allez devoir leur enseigner la culture du monde informatique. Tout dans l’informatique fonctionne mieux sans hiérarchie (développement, p2p, réseau de neurones, …).
Bonne chance Bruno, vous en aurez besoin face à la verticalité.
Bonjour,
Tu découvres les marchés publics… bienvenue ! Note que l’étape 4 donne lieu à la rédaction d’un document justificatif de dépouillement qui permet d’expliquer en quoi le choix retenu est le meilleur, d’après les critères annoncés dans l’appel d’offres. Ce document est vérifié par les responsables marché.
Il est parfaitement possible de favoriser un OS particulier ou un outil particulier, en citant la facilité d’intégration avec l’existant (par exemple) dans les critères de choix.
Enfin, il est tout à fait possible de commander des prestations de type SSII, si quelqu’un est capable de gérer le projet en interne (= servir d’interlocuteur technique à la SSII pour la définition précise du projet, etc).
Ton résumé donne l’impression que la procédure a été gérée de manière purement administrative en attendant une solution clés en mains… tout ça pour avoir un simple wiki !? C’est une vraie l’usine à gaz, côté client comme côté fournisseur. Vous allez le payer au prix du caviar, votre wiki…
L’autre solution, de moins en moins pratiquée dans l’administration, c’est de créer des postes techniques pour des personnes qui font le boulot « en interne », c’est à dire des administrateurs système, développeurs…
PS : je vois que tu avais déjà un passage sur la facilité d’intégration. Sur le critère « solution libre », il y a des solutions. Tu peux déjà au moins mettre un critère dans l’appel d’offres sur l’obtention des sources du logiciel. Donc dire qu’il est possible de favoriser Windows mais pas le libre, c’est du 100% pipeau de quelqu’un qui probablement sait comment favoriser Windows mais pas le libre.
En la matière il est fréquent qu’on te brandisse des habitudes purement locales comme si elles étaient des contraintes légales, histoire de couper court à toute discussion.
Si tu t’en sens le courage, ssaie de te procurer et de lire les parties pertinentes d’un code des marchés publics à jour, théoriquement ça doit se trouver sur http://www.marchespublicspme.com mais le site est à moitié en carafe (mysql…).
Il y a une autre solution c’est la regie. Un appel d’offre pour un gars et l’infra pour mettre en place tout ca pendant un an apres quoi on fait un appel d’offre pour recuperer l’infogerance et la maintenance evolutive.
Le gars met ca en place en discutant directement avec les utilisateurs.
Comme en plus un gars dans un sous sol avec un serveur ça coute la moitié de rien du tout une procedure adaptée super light est possible, voire on peut imputer sur un contrat cadre deja signé ( si les gens y ont pensé )
On me dit, en substance : « commander du temps sous quelque forme que ce soit est un emploi déguisé, c’est interdit pour les institutions publiques ». Peut-être que « commander un mec » « commander du temps », ceci dit.
@Bruno : va faire quelques recherches sur boamp.fr (publication de marchés) avec des mots clés comme « mission », « informatique », « audit »… ça te donnera une idée de ce qui est possible.
Voir également par exemple ces prestations de « conseil et réalisation » ces deux marchés émis par une entité bien connue :-)
http://boamp.fr/index.php?action=avis&num_parution=B20110001&num_annonce=95&total=2&_s=0&indice=0
http://boamp.fr/index.php?action=avis&num_parution=B20110001&num_annonce=96&total=2&_s=0&indice=1
Ah les achats de fournitures !
Les écoles obligées de passer par le fournisseur choisi par la Mairie après un appel s’offre, ce qui impose aux enseignantsde passer commande a partir d’un catalogue national dont les prix ne sont pas justes car pas ceux renégociés entre la ville et le fournisseur, prix en général infatuées au prix catalogue mais pas toujours. Pour n’apprendre qu’au moment de la toute fin de la saisie sur ordinateur quelle somme il leur reste tellement.
Et le mal au cœur a chaque rentrée scolaire quand on voit les catalogues des détaillants (Carrefour, Office Depot …) qui vendent Lea fournitures bien moins cher que legrossiste choisi par la ville (argh, 3 Typpex pour moins cher qu’un seul chez nous !)… déprimant.
Leave your response!
Dossiers
Derniers articles
Licence
Les contenus de ce blog sont, hors citations et images, sous licence Creative Common BY
Identité Ğ1
Catégories
Archives
Tags
Les autres
Mon bordel à moi
Recherches
Commentaires
Articles les plus commentés