Les tensions entre client et intégrateur apparaissent rarement parce que les équipes manquent de bonne volonté. Elles apparaissent plutôt quand les responsabilités restent implicites : qui décide, qui conseille, qui construit, qui valide, qui corrige et qui porte le fonctionnement après lancement.
Au début, cette imprécision semble souple. Elle permet d’avancer vite, de ne pas bloquer les ateliers et de laisser chacun “faire au mieux”. Mais dès qu’un choix devient coûteux, la souplesse se transforme en zone grise.
Sur un projet de développement web sur mesure, la relation client-intégrateur doit être organisée comme un système de décisions, pas seulement comme une prestation technique.
C’est encore plus vrai pour une application métier sur mesure, où les règles, les rôles, les données, les exceptions et le support engagent directement l’exploitation quotidienne.
Pourquoi les responsabilités floues coûtent plus qu’un retard
Un retard se voit. Une responsabilité floue se voit plus tard, quand une décision revient, quand une recette échoue, quand une règle métier change ou quand personne ne sait qui doit corriger un incident.
Le coût caché vient des reprises : décisions refaites, écrans modifiés, données requalifiées, tests rejoués et équipes remobilisées sur des sujets qui auraient pu être tranchés plus tôt.
Le flou protège la relation au début
Au lancement, personne ne veut alourdir le projet avec des règles trop strictes. Le client veut rester agile. L’intégrateur veut montrer qu’il sait accompagner. Cette ambiance facilite les premiers ateliers.
Le problème apparaît quand le projet a besoin d’un responsable identifiable. Sans cadre, chacun peut considérer que l’autre devait décider, alerter ou vérifier.
La clarté évite les faux conflits
Beaucoup de conflits projet ne viennent pas d’un désaccord profond, mais d’une attente non dite. Le client pensait que l’intégrateur sécuriserait un point. L’intégrateur pensait que le client validerait une règle.
Une répartition explicite transforme ces attentes en décisions lisibles.
Ce que le client doit posséder
Le client possède le sens métier, les priorités, les arbitrages de valeur et l’acceptation des compromis. Même avec un intégrateur très expérimenté, ces décisions ne peuvent pas être externalisées complètement.
Le client n’a pas besoin de tout savoir techniquement. Il doit en revanche savoir ce qu’il veut préserver, simplifier, refuser et assumer.
Les règles métier et les renoncements
Une règle complexe peut être nécessaire. Une exception rare peut coûter trop cher. Un parcours historique peut devoir disparaître. Ces décisions appartiennent au client, parce qu’elles touchent l’organisation.
L’intégrateur peut expliquer le coût et proposer des options, mais il ne doit pas décider seul ce que l’entreprise accepte de changer.
La priorité entre services et utilisateurs
Quand plusieurs équipes demandent des évolutions contradictoires, le client doit arbitrer. L’intégrateur peut structurer les impacts, mais la hiérarchie de valeur appartient à l’entreprise.
Sans cette responsabilité, le backlog devient un terrain de négociation permanente.
Ce que l’intégrateur doit porter
L’intégrateur porte la responsabilité de conseil, de conception technique, de qualité de réalisation, d’alerte et de transmission sur son périmètre. Il ne doit pas seulement exécuter des demandes.
Une bonne intégration consiste à transformer un besoin métier en solution fiable, maintenable et exploitable, tout en rendant les risques compréhensibles pour le client.
La qualité technique et les alertes
Architecture, sécurité, tests, performance, qualité des données, reprise d’incident, observabilité et maintenabilité relèvent du devoir d’alerte de l’intégrateur.
Si un choix demandé par le client met le système en risque, l’intégrateur doit le dire clairement, proposer des alternatives et documenter les conséquences.
La traduction des contraintes en options
Dire “c’est compliqué” ne suffit pas. L’intégrateur doit formuler des options : faire maintenant, différer, simplifier, automatiser partiellement, garder manuel ou auditer avant de décider.
Cette capacité de traduction rend le client capable de trancher sans devenir expert technique.
Ce qui doit être partagé sans être dilué
Certains sujets appartiennent aux deux parties, mais ils ne doivent pas devenir anonymes. Cadrage, recette, documentation, mise en production et passation exigent une responsabilité partagée avec un responsable identifié.
Partager ne veut pas dire mélanger. Chaque sujet partagé doit avoir une contribution claire côté client et côté intégrateur.
La recette métier
L’intégrateur prépare les conditions de test, corrige les défauts et explique les comportements attendus. Le client valide les règles, les usages, les exceptions et l’acceptabilité métier.
Si la recette est confiée uniquement à l’intégrateur, elle devient technique. Si elle est laissée uniquement au client, elle peut manquer de méthode et de traçabilité.
La documentation utile
L’intégrateur documente les choix techniques et les procédures. Le client documente les règles métier, les rôles internes et les décisions d’usage.
Une documentation utile relie ces deux niveaux. Sinon, elle reste correcte mais difficile à exploiter.
Décisions à attribuer avant le premier lot
Avant de construire le premier lot, il faut attribuer les décisions qui bloqueront le projet si elles restent floues. Ce travail prend peu de temps et évite beaucoup de reprises.
Décisions côté client
Priorité métier, périmètre du lot, validation des règles, disponibilité des utilisateurs, compromis acceptés, responsabilités de support et niveau d’autonomie attendu après lancement.
Décisions côté intégrateur
Architecture proposée, stratégie de tests, outillage, règles de qualité, dépendances techniques, mode de mise en production, points d’alerte et recommandations de découpage.
Décisions à arbitrer ensemble
Niveau de finition, profondeur de reprise, ordre de traitement des risques, degré d’automatisation, support au démarrage et calendrier de transfert de connaissance.
Responsabilités pendant la construction
Pendant la construction, le risque principal est de confondre avancement et alignement. Un lot peut avancer techniquement tout en s’éloignant de la décision métier initiale.
La responsabilité du client est de rester disponible sur les arbitrages. Celle de l’intégrateur est de rendre visibles les impacts quand les choix changent.
Le client doit répondre vite sur les points engageants
Toutes les questions ne méritent pas une escalade. Mais les sujets de règle, d’usage, de priorité et d’acceptation doivent avoir un délai de réponse connu.
Le guide Les signaux qu’une équipe projet manque d’un sponsor métier aide à repérer quand cette responsabilité n’est pas tenue.
L’intégrateur doit alerter avant que le coût ne soit irréversible
Une alerte utile arrive avant la construction complète d’une mauvaise option. Elle expose le risque, propose une décision et indique ce qui se passe si rien n’est tranché.
Responsabilités après la mise en production
La mise en production ne met pas fin aux responsabilités. Elle les rend plus concrètes : support, incidents, évolutions, supervision, droits, documentation et priorisation des corrections.
Un projet qui n’a pas clarifié l’après-lancement découvre souvent trop tard que personne ne sait vraiment qui doit agir.
Support de démarrage
L’intégrateur peut accompagner les premiers jours, analyser les erreurs, corriger les anomalies et surveiller les comportements techniques. Le client doit organiser les retours utilisateurs et prioriser les incidents métier.
Transmission et autonomie
Si l’entreprise veut reprendre une partie du run, cette autonomie doit être préparée : accès, documentation, runbook, décisions d’architecture, règles métier et contacts d’escalade.
Erreurs fréquentes dans la répartition
Les erreurs de répartition se voient souvent tard, car le projet avance malgré elles. Elles deviennent évidentes quand une tension arrive.
Erreur 1 : croire que le devis suffit à définir les responsabilités
Un devis décrit un périmètre, pas toujours un système de décision. Il faut compléter par des responsabilités opérationnelles claires.
Erreur 2 : laisser les règles métier à l’intégrateur
L’intégrateur peut modéliser et challenger une règle. Il ne doit pas décider seul de ce que l’entreprise accepte comme fonctionnement.
Erreur 3 : faire de la recette une simple vérification technique
La recette doit valider les usages, les exceptions et les responsabilités métier, pas seulement vérifier que l’écran ne plante pas.
Erreur 4 : oublier la passation jusqu’à la fin
Une passation tardive devient une réunion de rattrapage. Une passation préparée devient une trajectoire d’autonomie.
Guides complémentaires pour clarifier les rôles
Ces guides aident à relier la répartition client-intégrateur aux sujets de gouvernance, de sponsor, de partenaire et de modèle d’équipe.
Clarifier la propriété du projet
Le guide DSI, métier, produit, prestataire : qui possède le projet ? donne un cadre pour éviter les responsabilités implicites.
Repérer le manque de sponsor
Le guide Les signaux qu’une équipe projet manque d’un sponsor métier complète ce sujet côté décision métier.
Choisir le modèle d’équipe
Le guide Équipe interne, agence ou modèle hybride : arbitrer selon la maturité aide à ajuster la responsabilité selon l’organisation.
Sélectionner le partenaire adapté
Le guide Choisir un partenaire technique pour un projet web sur mesure montre comment vérifier la capacité d’un intégrateur à alerter et transmettre.
Conclusion : une responsabilité claire protège le projet
Répartir les rôles entre client et intégrateur ne sert pas à rigidifier la relation. Cela sert à rendre les décisions plus rapides, plus justes et plus assumées.
Le client doit posséder les arbitrages métier, la valeur, les priorités et les renoncements. L’intégrateur doit porter le conseil technique, la qualité, l’alerte, la réalisation et la transmission.
Les sujets partagés doivent rester nommés : recette, documentation, mise en production, support de démarrage et autonomie future. Partager une responsabilité ne doit jamais la rendre invisible.
Dawap accompagne les projets d’application métier sur mesure avec cadrage, architecture, gouvernance, intégration, recette et transmission pour que chaque acteur sache quoi décider, quoi porter et quoi transmettre.
