Marché public et site web : comment éviter de se faire enfermer six ans

Une collectivité me contacte rarement pour un premier site. Le plus souvent, elle en a déjà un, commandé il y a quatre ou cinq ans, et elle se rend compte qu'elle ne peut plus rien en faire sans repasser par le prestataire qui l'a construit. Changer un visuel, exporter les contenus, déménager l'hébergement : tout est bloqué, ou facturé au prix fort.

Ce n'est presque jamais une question de mauvaise foi. C'est une question de cahier des charges. Ce qui n'a pas été exigé au départ ne pourra pas être réclamé après. Et dans un marché public, le départ engage souvent pour six ans.

Le piège : on vous livre un site, pas les clés

Quand vous commandez un site, vous pensez acheter un site. En réalité, vous achetez surtout une prestation. La nuance paraît théorique, jusqu'au jour où vous voulez récupérer vos propres données et qu'on vous répond que ce n'est pas prévu.

Trois choses se retrouvent régulièrement coincées chez le prestataire : le code qui fait tourner le site, les contenus que vos agents ont saisis pendant des années, et l'hébergement, souvent sur un compte qui n'est pas le vôtre. Tant que tout va bien, personne ne s'en aperçoit. Le problème arrive le jour où vous voulez changer de prestataire, et que partir revient à tout reconstruire.

La réversibilité, le mot qui vous sauve

Le mot à connaître, c'est la réversibilité. Dans un marché public, c'est l'obligation pour le prestataire de vous rendre, en fin de contrat, tout ce qui vous appartient, dans un format exploitable par un autre.

Concrètement, une clause de réversibilité bien écrite prévoit qu'à la fin du marché, on vous remette le code source, une exportation complète de la base de données dans un format standard, les accès à l'hébergement, et la documentation pour reprendre le tout. Sans surcoût, parce que c'était prévu.

Cette clause ne sert à rien le jour de la signature. Elle sert tout le reste du temps. C'est elle qui transforme un prestataire en partenaire que vous gardez par choix, et pas par obligation.

Ce que je demande de vérifier dans un cahier des charges

Quand une collectivité me montre son cahier des charges avant de lancer une consultation, voici ce que je regarde en premier.

La propriété du code. Le code développé pour vous doit vous appartenir, ou être livré sous licence libre. Si le site repose sur une brique propriétaire que seul le prestataire maîtrise, vous êtes lié à lui pour la durée de vie du site.

L'hébergement et la localisation des données. Les serveurs doivent être en Europe, sur un compte dont vous êtes propriétaire. C'est une question de souveraineté, et c'est aussi du RGPD très concret. Vous ne voulez pas découvrir que les données de vos administrés vivent sur un compte au nom d'une agence.

L'accessibilité. Pour un site public, le respect du RGAA est une obligation légale. Exigez-le dans le cahier des charges, avec un audit à la livraison. Sinon vous payez deux fois : le site, puis sa mise en conformité.

La documentation et la formation. Un site qu'on ne peut pas faire vivre en interne est un site qui meurt lentement. Demandez la documentation et la prise en main de vos agents. C'est ce qui fait la différence entre un outil que vous pilotez et une boîte noire que vous subissez.

Le mini-guide : six questions qui démasquent le piège

Vous n'avez pas besoin d'être technicien pour repérer un prestataire qui va vous enfermer. Posez ces six questions, et écoutez moins la réponse que la façon de répondre. Un partenaire honnête répond sans hésiter. Un autre devient flou.

« À qui appartient le code à la fin du marché ? » La bonne réponse, c'est : à vous, ou sous licence libre. Si on vous parle d'un « socle maison » qui reste chez le prestataire, vous venez de trouver la laisse.

« Pouvez-vous m'exporter toute la base de données quand je le demande, dans un format standard ? » Oui, sans frais, c'est la réponse attendue. « C'est technique » ou « c'est prévu en option » veut dire non.

« L'hébergement sera-t-il sur un compte à mon nom, en Europe ? » Vos données, votre compte, vos serveurs. Si l'hébergement est « sur notre infrastructure », le jour du départ vous repartez les mains vides.

« Que se passe-t-il concrètement si je change de prestataire dans trois ans ? » C'est la question qui révèle tout. Un bon prestataire vous décrit la réversibilité sans broncher. Un mauvais se crispe et vous demande pourquoi vous feriez une chose pareille.

« Le site sera-t-il conforme RGAA, avec un audit à la livraison ? » Pour un site public, c'est une obligation, pas un supplément. Si on vous le facture en plus, on vous fait payer ce qui aurait dû être inclus.

« Mes agents pourront-ils gérer le contenu sans vous rappeler à chaque fois ? » Méfiez-vous du « on s'occupe de tout » : c'est une dépendance qui s'installe, avec le sourire. Ce que vous voulez entendre, c'est une formation et une documentation.

Gardez cette liste sous le coude au moment de la consultation. Elle tient sur une demi-page et elle vous évite six ans de regrets.

Pourquoi ça compte plus pour une collectivité que pour n'importe qui

Une entreprise qui se trompe de prestataire change l'année suivante. Une collectivité, elle, est tenue par la durée du marché et par les règles de la commande publique. Et l'argent public ne se dépense pas deux fois pour la même chose.

Un site public, ça doit pouvoir durer le temps d'un mandat, et survivre au changement de prestataire comme au changement d'équipe. Ça ne se décide pas à la livraison. Ça se décide dans les lignes du cahier des charges que presque personne ne lit jusqu'au bout.

C'est précisément là que je peux vous aider, avant même qu'une ligne de code soit écrite. Le bon moment pour penser à la sortie, c'est avant d'entrer.