V3.2 · Version de travail pour les comités de lectureCadre de relecture

Que vérifier avant de signer une offre informatique communale ?

Par Digitalisation-communes · Publié le

Fiche de méthode soumise aux comités de lecture.

Avant de signer une offre informatique, une commune devrait pouvoir expliquer ce qu’elle achète, le coût sur la durée retenue, les responsabilités de chaque partie et les conditions qui restent à lever. Un prix forfaitaire ne suffit pas à répondre à ces questions.

Commencer par réunir les pièces utiles

Nous recommandons de lire ensemble l’offre commerciale, ses annexes, les conditions d’exploitation, le planning, le dispositif de migration et les conditions de réception. Une promesse formulée dans un échange ne doit pas être confondue avec un engagement écrit. Lorsqu’une pièce manque, la conclusion est « à clarifier », et non « inclus par défaut ».

Le premier livrable peut être une liste très simple : document reçu, date, version, sujet couvert et élément manquant. Cela évite de comparer un devis récent avec une annexe devenue obsolète.

Examiner sept dimensions

  1. Périmètre : modules, utilisateurs, prestations incluses, exclusions et hypothèses qui conditionnent le forfait.
  2. Coût complet : investissement initial, abonnements, interfaces, exploitation, sortie et temps mobilisé par la commune.
  3. Migration et données : données reprises, nettoyage, responsabilités, essais et contrôles de rapprochement.
  4. Intégrations : échanges avec les autres systèmes, dépendances et tests de bout en bout.
  5. Responsabilités : qui réalise, qui valide, à quelle échéance et avec quelle preuve.
  6. Exploitation : support, engagements de service, maintenance, accès aux données et conditions de réversibilité.
  7. Préparation de la commune : disponibilités, arbitrages, tests métier, formation et organisation de la bascule.

Ces sept dimensions constituent notre grille de travail. Elles ne remplacent ni un audit technique exhaustif, ni une validation juridique, ni les critères officiels d’une procédure d’achat.

Transformer une réserve en demande précise

Écrire « la migration est risquée » aide peu à décider. Nous proposons de relier chaque constat à une conséquence, puis à une réponse attendue.

Exemple illustratif : les contrôles de migration sont annoncés, mais aucun protocole n’est joint. La réserve porte sur la possibilité d’accepter des données incomplètes. La demande devient : définir les totaux à rapprocher, les échantillons à vérifier, les responsables et les critères de rejet avant la bascule.

Pour chaque réserve, garder une trace de la pièce concernée, de la réponse reçue et de la personne chargée de la valider. Un point n’est pas fermé seulement parce qu’il a été discuté.

Préparer une décision défendable

Une fiche d’une page peut réunir le périmètre examiné, le coût connu, les inconnues, les conditions préalables et l’avis motivé. La commune conserve la décision. Une note moyenne favorable ne doit pas masquer un blocage déterminant.

Dans le cas entièrement fictif de Clairval, les conditions de migration et les interfaces illustrent ce raisonnement. Les montants et les acteurs y sont inventés ; il ne s’agit pas d’une référence client.

Pour poursuivre

Consulter la méthode « Avant de signer » et ses limites, puis notre guide pour calculer le coût complet d’un logiciel communal. Cette fiche synthétise les sept dimensions déjà présentées dans notre méthode.