Un contrat d’intégration qui fixe le périmètre, le prix et un planning, et rien d’autre, laisse la réalisation au bon vouloir de chacun. Avant de signer, réglez sept points par écrit : l’équipe nommée et le temps que chacun consacre à votre projet, la règle en cas de départ, la recette (qui teste, qui signe, quand un livrable est terminé), le responsable de la migration des données, la date à laquelle votre équipe exploite l’org seule, une documentation recettée comme tout autre livrable, et la clause de sortie. Tout point renvoyé au lancement sera tranché plus tard, sous la pression des délais, par celui qui a intérêt à le laisser flou.
La faille la plus fréquente touche l’équipe. La proposition met en avant un consultant principal qui a mené les ateliers de cadrage et sait pourquoi chaque choix de conception a été fait. Le contrat, lui, nomme la société, pas la personne. Une fois la conception terminée, ce consultant passe sur un autre client et son remplaçant est celui qui se trouve libre. Aucun engagement n’est rompu, puisque rien n’avait été promis, et vous payez désormais une nouvelle personne pour se réapproprier des décisions prises avant son arrivée.
Savoir qui décide et qui tranche les choix de conception relève de la sélection elle-même ; la note sur le modèle opérationnel à tester dans un appel d’offres Salesforce traite ces deux points. Celle-ci porte sur ce que le contrat signé doit contenir, une fois votre choix fait.
Qui compose l’équipe, et que se passe-t-il si quelqu’un part ?
La proposition présente une équipe, mais le contrat ne nomme le plus souvent que la société. Comblez l’écart en nommant les personnes qui assurent la réalisation : le directeur de projet, le consultant principal responsable de la conception et la personne qui conduit le travail sur les données. Pour chacune, inscrivez la part de son temps consacrée à votre projet et les phases qu’elle couvre. Sans taux d’affectation, un nom inscrit au contrat n’engage aucune part du temps de cette personne sur votre projet.
Des départs, il y en aura, et une clause qui les interdit ne sera pas respectée. Ce que vous pouvez fixer, c’est la règle. Un préavis écrit. Un profil de remplaçant que vous pouvez refuser. Un tuilage, payé par l’intégrateur, pendant que la nouvelle personne prend le relais. Aucun changement de directeur de projet pendant la réalisation ou la bascule sans votre accord. Ajoutez un nom de plus : la personne au-dessus du directeur de projet, celle que vous appelez quand le projet dérape.
Prenez le discours commercial pour ce qu’il est. La page partenaires de Salesforce oriente les acheteurs vers un annuaire de partenaires conseil et, séparément, vers des partenaires Forward Deployed Engineering, avec des études de cas qui citent des résultats allant de 15 M$ de pipeline commercial à 84 % de requêtes résolues de façon autonome. Ces résultats viennent d’autres clients et d’autres équipes, et il en va de même des études de cas d’une société, quel que soit son label de partenaire. Les personnes qui travailleront sur votre projet sont celles que nomme la clause d’équipe.
Quand un livrable est-il terminé, et qui signe la recette ?
C’est sur la recette que finissent les litiges avec un intégrateur, parce que c’est là que se croisent paiement et qualité. Écrivez-la dans le contrat lui-même, que les deux parties signent, et répondez à trois questions pour chaque livrable.
Qui teste. Vos utilisateurs clés, sur vos propres processus et sur des données proches de celles de production. L’intégrateur est présent pour corriger les anomalies pendant que vos utilisateurs testent.
Qui signe. Une personne nommée côté client pour chaque livrable, avec un suppléant pendant les congés. Un comité de pilotage n’est pas une signature, et l’intégrateur ne signe jamais sa propre recette.
Quand c’est terminé. Des critères écrits avant le début de la réalisation, une échelle de gravité convenue à l’avance et une règle de clôture, par exemple : aucune anomalie bloquante ouverte, toutes les autres listées avec une date de correction. Méfiez-vous de la recette tacite, qui répute un livrable accepté après un délai sans observation. Si cette clause demeure, le délai court à partir du moment où vos testeurs disposent à la fois de la version et des données, pas à la réception d’un message de l’intégrateur.
Liez ensuite chaque jalon de paiement à une recette signée, et non à une date du calendrier ou à l’avis de l’intégrateur annonçant qu’un livrable est prêt.
À qui revient la migration des données ?
Posez la question à chaque partie séparément : les réponses divergent souvent. La proposition indique que l’intégrateur « accompagnera » la migration ; le client comprend « réalisera ». Puis le premier chargement d’essai échoue sur des doublons que personne n’a été chargé de résoudre, et chaque partie accuse l’autre.
Les données et leur sens appartiennent au client. Une personne côté client, en général le responsable métier des données, répond donc du résultat de la migration : quels enregistrements migrent, quel doublon l’emporte, quel historique reste dans l’ancien système. L’intégrateur assure la mécanique pour laquelle il est payé : documents de correspondance, transformations, scripts de chargement, répétitions et rapports de rapprochement. Inscrivez ce partage dans le contrat. Précisez aussi qui extrait les données des systèmes existants, car cette tâche revient souvent à un tiers (l’éditeur de l’ancien système, une équipe informatique interne) qui n’est lié par aucun contrat sur ce projet.
Deux lignes de plus évitent la dispute habituelle : combien de répétitions complètes le prix comprend, et qui paie une répétition qui échoue parce que les données sources n’étaient pas prêtes. Ce qu’il faut prouver avant la bascule (un propriétaire par objet, des comptages signés par le métier, une heure limite de retour arrière) figure dans la note sur la migration de données Salesforce.
Quand votre équipe exploite-t-elle l’org seule ?
Inscrivez la date de passation dans le contrat : le jour où votre équipe exploite l’org seule et où l’intégrateur sort du circuit des mises en production. Puis planifiez à rebours.
Avant cette date, vos administrateurs ont travaillé aux côtés de l’intégrateur pendant la réalisation, plutôt que d’assister à une démonstration la dernière semaine, et la documentation (décisions de conception, notes de paramétrage, procédures de mise en production et de gestion des incidents) a été testée et signée comme tout autre livrable. Le plan de formation a aussi sa place ici : décidé avant la recette, pour que les utilisateurs clés testent ce qu’ils enseigneront ensuite. La note sur le plan de formation au lancement en fixe l’ordre.
Rendez la passation vérifiable. Avant la date, votre équipe réalise seule une mise en production, l’intégrateur se contentant d’observer. Si elle n’y parvient pas, la date est repoussée, et le contrat dit déjà qui paie le temps supplémentaire. Après la date vient une période de support, avec un périmètre écrit et des délais de réponse. Fixez-lui aussi une date de fin. Sans elle, le support se prolonge sans limite convenue, et vous continuez à le payer à des conditions que vous n’avez jamais négociées.
Comment partir si le projet tourne mal ?
Rares sont les clients qui signent en pensant partir, et c’est pourquoi la clause de sortie est celle que l’on reprend le plus souvent telle quelle du modèle. C’est aussi elle qui décide si vous gardez la main sur votre propre travail quand les choses tournent mal.
Une clause de sortie utilisable comporte quatre volets.
- Le droit de résilier le contrat sans motif, avec préavis, et pas seulement pour faute. Prouver la faute sur un projet en retard est long et contesté, et le projet continue de perdre du temps pendant que vous en débattez.
- Le transfert de tout ce qui a été produit (métadonnées, code, scripts, correspondances de données, cas de test, documentation), dans un état exploitable et en votre propriété.
- Une passation assistée vers l’équipe suivante, pour une durée définie et à des tarifs fixés dès aujourd’hui.
- Des accès détenus par le client dès le premier jour : comptes administrateur, identifiants d’intégration, environnements et dépôt de code. Partir ne doit jamais tourner à la négociation de mots de passe.
Lisez la clause de sortie en regard de la clause d’équipe. Si le responsable nommé part et que vous refusez deux profils de remplacement d’affilée, la sortie doit aussi s’ouvrir, sans avoir à prouver une faute.