Résumé

  • En février 2008, une université a perdu la possibilité de concourir pour environ 250 000 dollars à cause d’une incompatibilité de logiciel.
  • Les formulaires à remplir hors ligne devaient aider les usagers mal connectés ; leur maintenance devenait aussi une condition d’accès au financement.

Un dossier de subvention doit défendre un projet, justifier un budget, convaincre des lecteurs exigeants. Celui qu’une grande université publique américaine a envoyé en février 2008 s’est heurté à une exigence beaucoup plus sommaire : son logiciel était trop ancien pour le système qui le recevait.

L’université demandait environ 250 000 dollars pour une aide éducative à des communautés africaines. Grants.gov a rejeté son dossier pour incompatibilité de version. Impossible de le soumettre à nouveau avant l’échéance : l’établissement a perdu sa place dans la compétition. Le rapport de GAO de 2009 relate cet épisode sans nommer l’université. Le premier examen avait porté sur l’emballage informatique. Le projet attendrait un jury qui ne le verrait jamais.

Le guichet arrive sur le bureau

La conception du service répondait pourtant à une difficulté réelle. Selon le rapport de GAO de 2006, l’équipe de Grants.gov avait retenu des formulaires utilisables hors ligne pour réduire le temps de connexion des usagers ruraux. Héberger les dossiers inachevés et conserver de bonnes performances aurait également demandé davantage de matériel côté serveur.

Télécharger, travailler tranquillement, puis envoyer : la logique se défend. Encore fallait-il disposer de l’ordinateur convenable. Le logiciel de candidature fonctionnait sous Windows. Les établissements équipés de Macintosh avaient besoin d’une autre solution ; une réponse provisoire leur avait été proposée en décembre 2005. Ailleurs, les règles informatiques internes limitaient l’installation de programmes ou la circulation des fichiers.

Le bureau administratif s’était donc agrandi jusqu’au poste de travail du demandeur. Une partie des économies de connexion et de serveur se payait en installations, en autorisations locales et en surveillance des versions. Le bouton d’envoi réunissait enfin ces complications, généralement au moment où le calendrier devenait le moins indulgent.

Une retouche cosmétique avec mode d’emploi obligatoire

En septembre 2008, NIH annonçait le passage de PureEdge à Adobe pour ses formulaires et ceux d’organismes partenaires. La plupart des demandes électroniques adressées à NIH à partir de janvier 2009 devaient suivre ce changement, sous réserve des exceptions précisées dans l’avis. Les différences visuelles étaient présentées comme essentiellement cosmétiques. Mais une version d’Adobe Reader antérieure à 8.1.2 pouvait endommager le dossier lors du téléversement.

La cosmétique avait donc des dents. Deux formulaires d’allure familière pouvaient offrir des destins administratifs très différents.

L’avis conseillait de poursuivre la rédaction du projet et des pièces jointes, tout en attendant les nouveaux formulaires prévus pour décembre. Il fallait séparer le travail intellectuel de son contenant officiel. Publié après l’incident universitaire de février, ce document décrit une autre étape de la transition, avec ses propres consignes.

Cette histoire du Web public tient dans un déplacement discret : en choisissant le logiciel qui recevait les dossiers, l’administration choisissait aussi une condition d’entrée dans le concours. Une opération de maintenance pouvait dès lors décider si le fond serait seulement lu.