4.3. Les marchés publics
Le Web pose au responsable d'un programme public des problèmes qui relèvent de deux domaines toujours complexes : le contrat informatique et le contrat d'édition - en fonction d'ailleurs de ce que l'administration sous-traite.
Les contrats informatiques ont de longue date posé des problèmes difficiles à l'administration, en raison notamment de la nécessité de suivi et de la difficulté à changer de fournisseur pour des applications complexes. Par ailleurs, il est souvent difficile d'établir avec précision des budgets pour l'ensemble d'un projet.
Les contrats de numérisation, de réalisation de sites Web ou même de diffusion de banques de données sont relativement récents. Malgré cela, la réglementation générale des marchés publics a pu s'appliquer jusqu'ici, avec quelques aménagements particuliers. Cependant, des changements sont possibles en ce domaine, en raison de l'évolution rapide des technologies, des services possibles et du marché. Aussi faut-il se reporter au code des marchés publics et en particulier au Cahier des clauses générales administratives applicables aux prestations intellectuelles, et en général aux travaux, décisions et avis de la Commission centrale des marchés (CCM - voir site http://www.finances.gouv.fr), et en particulier au Groupement permanent d'étude des marchés - informatique et communication (GPEM-IC).
4.3.1. Une exigence de méthode
4.3.1.1 Etude préliminaire et cahier des charges
L'étude préliminaire est essentielle. La passation correcte, facile et sûre des marchés est étroitement dépendante de cette analyse initiale. La rédaction du cahier des charges est donc un acte très important - et beaucoup de sociétés constatent encore des imprécisions dans ces cahiers, qui sont en fait la cause de la plupart des difficultés rencontrées dans la passation puis dans l'exécution du marché et en général dans la gestion du projet.
4.3.1.2 Identifier précisément le projet et ses limites
Il faut isoler précisément le projet et ne pas mêler plusieurs objets, ni tout rattacher à un projet : une première tâche consiste à distinguer précisément ce qui, dans un développement particulier, relève du projet et ce qui relève en fait d'autres opérations, de renouvellement courant etc. La taille des marchés, et donc les règles qui vont s'appliquer, dépendent de cette affectation. C'est ainsi que l'achat d'ordinateurs, souvent lié au projet, relève en général d'autres marchés, qui sont ceux du plan d'équipement. Il en est de même d'infrastructures de télécommunication etc. Très légitimement, ces équipements, ainsi que certains développements logiciels de base, peuvent être imputés à des plans existants ou à des opérations autonomes, car ils auront en général des usages multiples. Il est donc en général préférable de rattacher les éléments courants à des marchés existants.
4.3.1.3 Analyse et lots
L'analyse du projet va ensuite permettre de déterminer des lots, ce qui permet d'ouvrir au maximum le marché à la concurrence et de le décomposer en éléments beaucoup plus facile à gérer et administrativement bien définis. Le fait de distinguer des lots n'empêche d'ailleurs pas de les grouper, ou de confier plusieurs lots à un même contractant. Cependant, cette approche facilite la gestion, contraint à une analyse précise du projet et permet de transférer ensuite certains lots à d'autres opérateurs, le cas échéant.
Cette démarche n'interdit pas de faire appel à un intégrateur / coordonnateur / responsable de l'architecture d'ensemble. En fait, pour des projets importants, un lot particulier peut être défini, qui correspond à l'intégration.
Les lots identifieront clairement les études, les matériels et logiciels éventuels, les opérations de numérisation initiale, le développement pour la mise en ligne, les opérations courantes de numérisation, l'hébergement de services, les diverses maintenances etc.
Le calendrier doit être établi avec précautions, et il est en général très pertinent de découper en phases. Il doit tenir compte, comme toute la formulation du marché, de la vitesse d'évolution des produits en informatique. Il ne faut ainsi effectuer les choix techniques que lorsque c'est approprié, et donc le plus tard possible, pour disposer des solutions récentes.
4.3.1.4 Approche fonctionnelle
L'approche fonctionnelle doit être privilégiée. Pour faire face à la vitesse d'évolution de l'offre informatique et de services, il importe surtout que l'ensemble des contrats porte plus sur des fonctions que sur des outils particuliers. Si une solution technique est retenue dès le début d'une phase ou de l'ensemble d'un projet, il faut pouvoir, par un avenant, modifier cette solution le cas échéant. Cela est possible dans le cas de marchés passés à une SSII, qui fait son affaire de l'installation des différentes solutions - et dans le cadre d'un lot passé à une seule société. Dans le cas où le fournisseur d'un matériel ou d'un progiciel est co-traitant, il ne sera évidemment pas possible de changer de fournisseur pour ce marché, alors que ce sera envisageable s'il n'était que sous-traitant.
Si le marché comprend du matériel et du logiciel, il peut relever des marchés publics industriels, dont l'article 19 prévoit des modifications techniques. Cet article offre plusieurs options, et il sera en général préférable de se référer à l'option A, qui confère à la personne publique des droits assez étendus et qui permet de demander à la société prestataire de fournir les codes source dans le cas de développement d'un logiciel.
4.3.1.5 Les normes
La référence aux normes s'impose dans les marchés publics, mais il s'agit seulement d'une référence, que le prestataire est tenu de fournir s'il existe une norme homologuée adaptée. L'administration ne peut demander l'utilisation d'une norme particulière (sauf cas particuliers de sécurité où les normes s'imposent à tous) et elle n'y fait pas elle-même obligatoirement référence dans l'appel d'offres - ce qui ne veut pas dire que la conformité à une norme ne soit pas un élément important du choix.
4.3.2. Les formes et les solutions de flexibilité
Le responsable d'un projet est confronté à deux causes d'incertitude : il est difficile d'évaluer précisément les charges pour des programmes nouveaux, et il est difficile de maîtriser les évolutions des techniques et des usages sur le Web et sur les médias de diffusion électronique en général. Il faut donc pouvoir introduire des facteurs de souplesse dans les marchés.
Pour passer contrat avec des prestataires privés, on peut imaginer plusieurs formes contractuelles, qui peuvent dailleurs être cumulées.
4.3.2.1 L'utilisation de bons de commande
Pour disposer de souplesse dans lexécution du chantier de numérisation et du site Web, en même temps que pour réduire les phénomènes de dérapage des coûts de réalisation, le service administratif concerné peut adresser au coup par coup des bons de commande à son prestataire, après avoir convenu avec lui de fonctionner de cette manière.
Cette méthode de travail permet de gérer le déroulement du marché. Cependant, elle ne permet pas, à elle seule, de prendre en compte l'incertitude sur le montant global. Or, l'un des problèmes les plus difficiles au début d'un projet est de mesurer exactement la charge de travail.
En numérisation, l'analyse du fonds sera menée conjointement au lancement du travail, car il serait absurde, voire impossible, de préparer tous les documents puis de passer un marché. Dès lors, une inconnue demeure : la charge réelle de numérisation. La solution va être de passer un marché par tranches, mais évidemment toujours avec le même fournisseur, et il s'agit donc bien d'un marché unique.
Pendant un temps, la solution retenue a été celle du marché à commande. Dans un tel marché, une enveloppe est définie et, à l'intérieur de cette enveloppe, le marché est réalisé par la passation de commandes. En fait, ce type de marché concerne les réalisations d'investissement et les commandes doivent s'en tenir à des tarifs par prestations, initialement fixés (notamment les charges correspondant aux différentes catégories de personnel) et aux prix définis pour les différents matériels. Ainsi, pour du matériel électrique, les tarifs catalogue étaient référencés dans le marché. Cependant, s'agissant de prestations intellectuelles et de travaux informatiques, il ne paraît en fait pas adapté de se référer à cette démarche, qui s'adapte mieux au cas où il est possible d'organiser la commande autour d'un matériel référencé.
Pour les développements informatiques, la méthode recommandée par la Commission spécialisée des marchés informatiques (CSMI) est de raisonner par unité d'oeuvre, et non par intervenant, charge de travail etc. On se ramène ainsi à un produit.
Un cahier des charges précis doit être établi. Pour tenir compte de l'incertitude initiale, il est alors possible de prévoir une partie à bon de commande variable, mais elle ne doit pas excéder 10% du marché. L'administration doit avoir défini ce qu'elle veut et la marge en question ne doit porter que sur le volume exact des prestations. Celles-ci doivent être strictement définies sur le plan technique : c'est exactement le cas pour un plan de numérisation, et cela donne une marge de manoeuvre de 10%. Dans le marché présenté à la CSMI, il faut qu'on puisse calculer automatiquement le montant d'une prestation qui serait commandée dans la partie à commande, par le produit Nombre d'unités d'oeuvre x tarif.
L'idée est d'avoir défini dans le cahier des charges (CCTP) un certain nombre de prestations standards (unités d'oeuvre de graphisme : combien ça coûte et qu'est-ce que ça couvre, unité d'oeuvre de saisie de texte : combien de caractères pour quel prix, etc.), qu'il ne suffira plus que de commander en plus ou moins grande quantité selon ce que l'on a à réaliser.
A chaque besoin d'évolution, l'administration n'a plus qu'à demander un devis au titulaire du marché, qui lui répondra combien d'unités d'oeuvre de chaque catégorie de taches sont nécessaires: par exemple, 15 unités d'oeuvre pour le graphisme, 1 unité d'oeuvre pour la création de liens, 12 unités d'oeuvre pour la saisie des textes, 8 unités d'oeuvre pour la création de bandeaux, etc. Il ne reste plus alors à l'administration qu'à émettre un bon de commande du nombre d'unités d'oeuvre correspondant.
4.3.2.2 La convention de prix.
L'article 34.1 du code de passation des marchés publics prévoit que plusieurs organismes peuvent se regrouper face à leurs prestataires, lorsqu'ils présentent un cahier des charges commun. Les prestations requises sont précisées dans le cahier des clauses techniques des administrations et dans le cahier des clauses administratives particulières. Ensuite, chaque service n'a plus à engager un marché sur les bases de cette convention, les conditions étant les mêmes pour tous les organismes regroupés. Cette façon de procéder permet d'obtenir des réductions tarifaires auprès des prestataires et d'assurer un meilleur contrôle technique.
4.3.2.3 Propriété et protection
Il est impératif d'insérer une clause conservant à l'administration une copie conforme de son site en local, dans le cas où celui-ci est hébergé chez le prestataire; cette copie est la première sécurité en cas de nécessité de changement de prestataire.
De même, des clauses concernant la propriété littéraire et artistique devront prévoir que les auteurs du site, de son graphisme et de son "look and feel" cèdent à l'administration leurs droits patrimoniaux afin d'éviter les contentieux en cas de changement de prestataire.
(cf. pour les autres aspects "Le cadre juridique")
© Ministère de l'Économie, des Finances et de l'Industrie, 19/05/1999