Un prestataire technique ne remplace pas un référent interne

Dans le cadre de mon accompagnement du Comité international des Jeux de la Francophonie, j’interviens entre plusieurs réalités : l’administration quotidienne du site, la production éditoriale, la migration d’archives, le suivi des tickets, les besoins de l’équipe, les contraintes de la DSI et les échanges avec le prestataire technique. Cette position montre à quel point un projet numérique se joue rarement dans le seul outil de gestion de projet.

Une demande apparemment simple peut avoir des effets sur les droits utilisateurs, la structure des contenus, la reprise de données ou le travail éditorial. Une réponse techniquement correcte peut rester inutilisable au quotidien. À l’inverse, une difficulté présentée comme « technique » vient parfois d’une règle métier qui n’a jamais été explicitée.

Le rôle du référent consiste alors à relier les sujets. Il conserve le contexte des décisions, vérifie qu’une correction traite bien le problème rencontré et évite que chaque interlocuteur ne voie qu’un fragment du système. Les situations évoquées dans cet article sont volontairement généralisées : elles décrivent des risques de gouvernance que je rencontre dans ce type de mission, pas le procès d’une entreprise en particulier.

Un cahier des charges peut contenir une mauvaise hypothèse, un parcours contradictoire ou une interaction contraire aux usages établis. Le client peut demander une fonction qui semble logique sur le papier mais qui produit des impasses, multiplie les manipulations ou rend une prochaine évolution très coûteuse.

Exécuter cette demande à la lettre permet ensuite de dire que la livraison respecte les spécifications. Contractuellement, l’argument peut être recevable. Professionnellement, il ne suffit pas toujours. Lorsqu’un prestataire vend aussi de l’architecture, de la conception ou du conseil, sa valeur ne réside pas seulement dans sa capacité à construire. Elle réside aussi dans sa capacité à signaler une conséquence prévisible avant qu’elle ne soit intégrée au produit.

Une bonne alerte ne consiste pas à bloquer le projet. Elle formule le risque, propose une solution raisonnable et laisse une décision documentée : « cette interaction créera telle difficulté ; voici l’alternative recommandée ; si vous maintenez la demande, voici les conséquences connues ». Sans cette trace, l’institution découvre le problème après la livraison, au moment où le corriger devient une évolution facturable.

Le client ne peut pas toujours distinguer une contrainte réelle, un choix d’architecture, une limite du produit et une préférence du prestataire. Cette asymétrie est normale jusqu’à un certain point : c’est précisément pour accéder à cette expertise que l’institution fait appel à un spécialiste. Elle devient dangereuse lorsque les risques connus ne sont pas explicités au moment de décider.

Le mécanisme est simple. Une spécification fragile est acceptée sans réserve. La fonctionnalité est livrée conformément à la demande. Les utilisateurs rencontrent ensuite les difficultés qui auraient pu être anticipées. La correction sort alors du périmètre initial et fait l’objet d’un nouveau devis. Qu’il résulte d’une intention commerciale ou d’un défaut de conseil, l’effet pour le client est le même : il paie d’abord pour construire le problème, puis pour le corriger.

Il ne s’agit pas de considérer toute évolution comme suspecte. Un produit vivant doit évoluer, et de nouveaux besoins apparaissent réellement. La question est de savoir si l’évolution répond à un apprentissage imprévisible ou répare une faiblesse que l’expertise annoncée aurait dû faire remonter plus tôt.

Lorsqu’un incident apparaît, le problème peut rapidement être attribué à l’organisation : demande imprécise, validation tardive, contenu mal préparé, utilisateurs insuffisamment formés. Ces causes existent. Une institution a elle aussi des responsabilités et doit pouvoir les reconnaître.

Mais sans référent interne, elle dispose rarement des éléments nécessaires pour distinguer une faute de préparation, un défaut de conseil, une livraison incomplète ou une limite acceptée en connaissance de cause. Les échanges se dispersent entre réunions, messages et tickets. La raison d’une décision disparaît. Une réserve formulée oralement devient introuvable, tandis qu’une validation sortie de son contexte prend valeur de preuve définitive.

Le référent ne sert donc pas à contester systématiquement le prestataire. Il rétablit une discussion fondée sur des faits : besoin initial, scénario testé, décision prise, alerte reçue, critère d’acceptation et résultat observé.

Le référent technique interne n’est ni un chef de projet qui transmet des messages, ni un développeur de secours. Il organise la capacité de l’institution à décider. Sa compétence principale est de faire le lien entre l’usage, la technique et le contrat.

Il doit pouvoir reformuler une demande sous forme de parcours concret, repérer les cas limites, demander comment les données sont stockées et récupérées, comprendre les dépendances critiques et vérifier que les critères de recette mesurent autre chose que la présence d’un bouton. Il doit aussi savoir dire qu’une demande interne est mauvaise, même lorsqu’elle vient d’un décideur.

Sa formation doit couvrir les bases de l’architecture web, de la sécurité, de l’accessibilité, de la protection des données, des interfaces et de la gestion de produit. L’objectif n’est pas d’en faire un expert de chaque domaine, mais de lui donner assez de repères pour savoir quand exiger une explication ou solliciter un avis indépendant.

La présence d’un référent n’est utile que si son rôle est reconnu. Il doit participer au cadrage avant le chiffrage, disposer du temps nécessaire pour tester et pouvoir demander qu’un risque soit consigné. Il doit également avoir accès aux interlocuteurs capables de répondre, notamment lorsque le prestataire met en avant une expertise d’architecture.

Les spécifications importantes devraient présenter le besoin et le résultat attendu avant d’imposer une solution. Pour chaque choix structurant, le prestataire devrait préciser les conséquences, les alternatives écartées et les limites connues. La recette devrait suivre des parcours complets, y compris les erreurs et les exceptions, plutôt qu’une liste d’écrans à valider.

Enfin, le contrat et le suivi doivent distinguer clairement la correction d’une non-conformité, l’évolution issue d’un nouveau besoin et la remise en cause d’un choix dont le risque avait été accepté. Cette distinction ne supprime pas les désaccords, mais elle empêche qu’ils soient systématiquement réglés par celui qui possède le plus d’information technique.

Cette fonction n’a pas pour but d’installer une méfiance permanente. Un prestataire sérieux travaille mieux lorsque les besoins sont arbitrés, les retours consolidés et les responsabilités claires. Il perd moins de temps dans les demandes contradictoires et peut défendre une solution robuste face à une préférence interne mal informée.

Le référent protège donc l’institution contre sa dépendance, mais aussi le projet contre les décisions prises sans contexte. Il rend visibles les désaccords assez tôt pour qu’ils restent peu coûteux.

Une organisation qui confie un produit numérique stratégique à l’extérieur doit conserver en interne la capacité de comprendre ce qu’elle achète. Sans cette compétence, elle ne délègue pas seulement la réalisation : elle délègue progressivement ses choix, sa mémoire et sa faculté de contester une solution qui ne sert plus ses utilisateurs.