Création et configuration des comptes : le socle technique de l'onboarding

Par Tara Minh · Mis à jour le 14 juillet 2026

Une entreprise SaaS a suivi pendant six mois les problèmes rencontrés par ses clients et a fait une découverte éclairante : 62 % des tickets de support des mois 2 à 6 remontaient à des choix de configuration faits lors du paramétrage initial.

Une structure de permissions inadaptée, et c'étaient des demandes d'accès à répétition. Un workflow mal configuré, et les utilisateurs bricolaient des contournements. Des intégrations manquantes, et il fallait saisir à la main des données qui auraient dû être automatisées. Une migration de données bâclée, et c'étaient des mois de nettoyage.

Les équipes qui expédient la configuration technique pour « mettre les clients plus vite sur le produit » finissent par un onboarding plus lent et une adoption plus faible, parce qu'elles ont construit sur des fondations bancales.

Si vous voulez un onboarding qui mène à une réussite durable, il faut poser le bon socle technique. Pas parfait, mais juste : une configuration qui répond au véritable cas d'usage du client et qui évolue avec sa croissance.

Pourquoi la configuration technique compte plus qu'on ne le pense

La plupart des équipes voient la création de compte comme une corvée administrative : ouvrir les comptes, activer quelques options, passer la main à la formation. C'est une erreur.

La configuration technique détermine si les workflows correspondent à la façon dont le client travaille réellement (ou s'il doit s'adapter aux hypothèses de votre produit). Si les intégrations livrent les données au bon moment et sous la bonne forme (ou si elles imposent des rapprochements manuels). Si les permissions reflètent son organisation (ou si elles créent des failles de sécurité et des frictions). Si la migration apporte des données propres et exploitables (ou un fatras qui sape la confiance dans le système).

Les utilisateurs mettent sur le dos du « produit » des problèmes qui relèvent en réalité de la configuration. Ils ne disent pas « nous avons mal configuré ceci ». Ils disent « ce produit ne nous convient pas », puis ils partent.

Le coût d'une mauvaise configuration technique

Quand on précipite le paramétrage, les coûts à court terme s'accumulent vite. Les délais d'onboarding s'étirent sur des semaines, voire des mois, le temps de refaire les configurations. Le volume de tickets de support explose. Les sessions de formation ne correspondent pas à l'état réel du système : vous apprenez aux gens à utiliser quelque chose qui n'existe pas. Les utilisateurs se frustrent et se braquent. Vos CSM passent leur temps à corriger des problèmes au lieu de stimuler l'adoption.

À long terme, c'est pire. L'adoption baisse parce que les workflows ne collent pas à la réalité. La dette technique alourdit durablement le support. Les utilisateurs inventent des contournements qui court-circuitent complètement votre produit. L'expansion devient difficile, car le socle est instable. Le churn augmente parce que la valeur met du temps à se concrétiser.

Corriger coûte moins cher que subir. Investir 5 à 10 jours de plus dans un paramétrage soigné fait économiser des mois de nettoyage et évite des problèmes d'adoption par la suite.

Préparation en amont : la phase de découverte

Avant de toucher à la moindre configuration, vous devez comprendre ce que vous construisez.

Recueil des exigences techniques

Commencez par les questions d'infrastructure et d'environnement. Le client a-t-il des exigences d'hébergement : cloud, sur site, déploiement dans une région précise ? Quelles contraintes de réseau et de pare-feu faut-il prendre en compte ? A-t-il besoin d'un accès API, et si oui, depuis où ? La plupart des clients ont besoin d'environnements distincts pour le développement, la préproduction et la production. Quelles sont leurs exigences de montée en charge et de performance ?

Posez les questions franchement : « Y a-t-il des restrictions réseau dont nous devons tenir compte ? » Ne supposez pas que l'équipe pare-feu ouvrira tout sans discuter. « Avez-vous besoin d'environnements séparés pour les tests et la production ? » paraît basique, mais beaucoup de clients n'y ont pas réfléchi. « Quelles sont vos exigences de disponibilité et de performance ? » pèse davantage pour les systèmes critiques. « Existe-t-il des exigences de résidence géographique des données ? » revient de plus en plus souvent avec les réglementations sur la vie privée.

Revue de la sécurité et de la conformité

Les exigences de sécurité doivent être clarifiées dès le départ, car elles ajoutent des semaines au calendrier si elles surgissent en cours de projet.

Authentification unique (SSO) et configuration du fournisseur d'identité. Exigences d'authentification multifacteur. Politiques de mots de passe et d'accès. Exigences de liste blanche d'adresses IP. Normes de chiffrement des données. Exigences de journalisation d'audit. Pour beaucoup de clients, ce ne sont pas des options de confort : ce sont des conditions bloquantes pour la mise en production.

Les exigences de conformité comptent tout autant. Réglementations sectorielles comme HIPAA, RGPD, SOC 2. Politiques de confidentialité et de conservation des données. Questionnaires ou évaluations de sécurité à remplir. Processus d'évaluation des risques fournisseur. Besoins en documentation de conformité.

Les questions à poser : « Quelles normes de sécurité et de conformité devons-nous respecter ? » pour ouvrir la discussion. « Avez-vous besoin du SSO ? Avec quel fournisseur d'identité ? », car il en existe des dizaines et la configuration varie. « Quelles réglementations sur la vie privée s'appliquent ? », car les clients cumulent souvent plusieurs exigences. « Devez-vous examiner notre documentation de sécurité ? » pour savoir s'il existe un processus de revue formel. « Y a-t-il des exigences particulières d'audit ou de journalisation ? » pour repérer les besoins de traçabilité spécifiques.

Signal d'alerte : si des exigences de sécurité ou de conformité apparaissent une fois la configuration lancée, attendez-vous à des semaines de retard. Obtenez cette information en amont, pendant la vente ou le lancement.

Exigences d'intégration

Vous devez savoir quels systèmes doivent s'intégrer à votre plateforme. Systèmes CRM comme Salesforce ou HubSpot. Plateformes de marketing automation comme Marketo ou Pardot. Agenda et messagerie via Google Workspace ou Microsoft 365. Systèmes de comptabilité et ERP. Entrepôts de données ou plateformes d'analyse. Systèmes internes spécifiques via API.

Pour chaque intégration, précisez les détails. Quelles données doivent être synchronisées ? La synchronisation est-elle unidirectionnelle ou bidirectionnelle ? À quelle fréquence doit-elle avoir lieu (en temps réel, toutes les heures, chaque jour) ? Qu'est-ce qui la déclenche (un événement ou une planification) ? Qui est responsable de l'intégration côté client, c'est-à-dire qui peut réellement accorder l'accès API ? Le partage de données entre systèmes soulève-t-il des questions de conformité ?

Les questions pratiques : « Quels systèmes doivent s'intégrer à notre plateforme ? », puis « Quelles données doivent circuler entre les systèmes ? », car le client ne pense pas toujours aux détails. « Qui, dans votre équipe, gère chaque système et peut accorder les accès ? » compte beaucoup : vous perdrez des semaines à attendre la mauvaise personne. « Existe-t-il des politiques de gouvernance des données à respecter ? » fait ressortir tôt les blocages potentiels.

Planification de la migration des données

Commencez par le périmètre. Quelles données sont migrées (contacts, comptes, transactions, historique) ? De quel volume parle-t-on (nombre d'enregistrements, taille des fichiers) ? Depuis quelles sources (ancien système, tableurs, export de base de données) ? Quelle est la qualité des données (doublons, champs manquants, problèmes de format) ? Quel est le calendrier de migration (bascule en une fois ou approche progressive) ?

Évaluez la qualité des données dès le début. Obtenez un échantillon d'export pour juger de la qualité avant de vous engager sur quoi que ce soit. Repérez les doublons, les champs obligatoires manquants, les incohérences de format. Estimez l'effort de nettoyage nécessaire et qui en est responsable (client ou éditeur). Fixez des attentes réalistes sur la qualité des données après la migration.

Posez les bonnes questions : « De quelles données avez-vous besoin dans le nouveau système pour être productifs ? » distingue l'indispensable du souhaitable. « Pouvez-vous fournir un export d'échantillon pour que nous évaluions la qualité ? », car on ne planifie pas une migration sans voir les données réelles. « Qui est responsable du nettoyage des données de votre côté ? » établit la responsabilité. « L'historique est-il indispensable, ou peut-on repartir de zéro pour certains enregistrements ? », car il vaut parfois mieux repartir sur une base saine.

Ne promettez pas de « tout migrer » sans connaître le volume et la qualité. Migrer de mauvaises données prend exponentiellement plus de temps que migrer de bonnes données.

Création des comptes et gestion des utilisateurs

Création et structure des comptes

Commencez par la hiérarchie de l'organisation. Création du compte entreprise. Structure par business unit ou par équipe si le client compte plusieurs divisions. Configuration des sites ou des bureaux si elle a un effet sur les permissions ou le reporting. Toute exigence multi-tenant ou de marque blanche qui influe sur l'architecture du compte.

Configurez les paramètres de base du compte : nom de l'entreprise, logo, identité visuelle. Langue principale et paramètres régionaux. Fuseau horaire correspondant au siège ou au site principal. Préférences de format de date et d'heure. Paramètres de devise pour les données financières.

Création des comptes utilisateurs et des rôles

Vous avez trois approches pour la création des utilisateurs, et le bon choix dépend de la taille du client et du niveau d'accompagnement.

Approche enterprise en accompagnement renforcé (high-touch) : le CSM crée tous les utilisateurs. Vous importez la liste fournie par le client, préconfigurez les rôles et les permissions, puis envoyez les e-mails d'invitation. Elle convient aux clients grands comptes, aux structures de rôles complexes et au service en accompagnement renforcé, quand vous voulez garder la main sur tout.

Approche en accompagnement intermédiaire (mid-touch) : le CSM crée uniquement les comptes administrateurs. Les administrateurs du client créent les comptes de leurs équipes. Vous fournissez des conseils et des modèles. Elle convient aux clients mid-market dont les administrateurs sont capables de gérer les utilisateurs.

Approche en accompagnement léger ou product-led growth : les utilisateurs s'inscrivent eux-mêmes. L'administrateur valide et attribue les rôles. Des parcours d'onboarding automatisés guident la configuration. Elle convient aux clients PME, aux démarches product-led growth et aux produits simples pour lesquels le self-service a du sens.

La définition des rôles doit refléter l'organisation du client. Le rôle Administrateur donne un accès complet au système, à la configuration et à la gestion des utilisateurs. Le rôle Manager donne la supervision de l'équipe, le reporting et une configuration limitée. Le rôle Utilisateur donne l'accès standard au produit pour le travail quotidien. Le rôle Lecture seule donne accès aux rapports et à la visibilité sans modification. Des rôles personnalisés sont taillés sur mesure pour la structure du client quand les rôles standard ne conviennent pas.

Démarrez avec des permissions restrictives et élargissez-les au besoin : c'est plus simple que de les retirer ensuite. Calquez-vous sur la structure du client, pas sur vos idées de la façon dont il devrait s'organiser. Documentez qui a accès à quoi et pourquoi. Créez des modèles de rôles pour les cas courants. Passez les permissions en revue et auditez-les régulièrement.

Configuration du SSO et de l'authentification

La configuration du SSO suit un processus prévisible, mais la coordination compte plus que les étapes techniques.

Recueillez les informations sur le fournisseur d'identité du client (Okta, Azure AD, Google, autres). Échangez les métadonnées : le client vous envoie les métadonnées de son IdP, vous lui envoyez celles de votre SP. Configurez la correspondance des attributs pour l'e-mail, le nom, le rôle et les autres champs de profil. Testez le SSO avec un utilisateur de test avant la mise en production. Activez-le pour les utilisateurs de production une fois les tests concluants. Conseillez le client sur la création des utilisateurs, en juste-à-temps ou manuelle.

Les pièges courants à surveiller : les équipes IT des clients exigent souvent une revue de sécurité qui ajoute 2 à 3 semaines au calendrier. Des erreurs de correspondance des attributs provoquent des échecs de connexion pénibles à diagnostiquer. Les clients croient que le SSO est instantané, alors qu'il demande de la coordination entre équipes. Des utilisateurs se retrouvent bloqués si le SSO est mal configuré, ce qui fait une très mauvaise première impression.

La configuration du MFA est simple dès lors que vous connaissez les exigences. Déterminez si le MFA est imposé par la politique du client ou par la conformité. Configurez la méthode de MFA (SMS, application d'authentification, clé physique). Testez le parcours MFA. Documentez la procédure de récupération en cas de blocage, car les utilisateurs perdront leurs appareils.

Configuration du système cœur

Configuration des workflows et des processus métier

Cartographiez l'existant avant de configurer quoi que ce soit. Comment le client réalise-t-il ce processus aujourd'hui ? Quelles étapes, validations et notifications sont nécessaires ? Qui intervient à chaque étape ? Quels sont les critères de réussite et les exceptions ?

Concevez ensuite la situation cible. Comment le processus fonctionnera-t-il dans votre produit ? Quelles étapes de workflow, quels déclencheurs et quelles automatisations ? Quelle personnalisation ou configuration est nécessaire ? Quelles règles métier faut-il faire respecter ?

Prenons l'exemple de la validation des factures. Situation actuelle : l'employé envoie la facture par e-mail. Le manager reçoit l'e-mail, la vérifie et répond par son accord. La finance la saisit manuellement dans le système comptable. La finance traite le paiement.

Situation cible dans votre produit : l'employé soumet la facture directement. Acheminement automatique vers le manager selon des règles, comme le montant et le service. Le manager valide dans le produit, et une notification part automatiquement par e-mail. Synchronisation automatique avec le système comptable via une intégration. La finance est notifiée pour traiter le paiement.

Configuration requise : un générateur de workflow pour gérer le passage Soumission, Validation, Finance. Des règles de validation qui acheminent selon le montant (plus de 5 000 \(vers le directeur, moins de 5 000\) vers le manager). Des modèles de notification pour le manager et la finance. Une intégration pour envoyer les factures validées vers QuickBooks.

Champs et objets personnalisés

Créez des champs personnalisés quand le client a des données propres à son secteur ou à son activité. Quand ils sont nécessaires au reporting ou à la segmentation. Quand ils servent à la correspondance des intégrations. Quand ils sont déterminants pour la logique du workflow.

Bonnes pratiques : ne créez que les champs qui seront réellement utilisés. Résistez aux champs « au cas où » qui encombrent l'interface. Appliquez des conventions de nommage cohérentes. Définissez avec soin les types de champs (texte, nombre, date, liste déroulante). Choisissez à bon escient entre obligatoire et facultatif. Documentez l'objectif et l'usage de chaque champ personnalisé.

Des exemples pertinents : l'opportunité commerciale reçoit « Source de recommandation partenaire » sous forme de liste déroulante. Le ticket de support reçoit « Composant produit » sous forme de liste déroulante pour le tri par l'ingénierie. Le compte client reçoit « Motif de risque de renouvellement » sous forme de champ texte pour le suivi par l'équipe CS.

Règles d'automatisation et déclencheurs

Quelques schémas d'automatisation courants règlent les tâches répétitives. Affectation automatique : un nouvel enregistrement est créé, il est attribué à un responsable selon des règles. Notifications : changement de statut, envoi d'un e-mail aux parties prenantes. Escalades : un enregistrement reste X jours dans un état, il est escaladé au manager. Mises à jour de données : le champ A change, le champ B se met à jour automatiquement. Actions inter-objets : un enregistrement est créé dans le système A, un autre est créé dans le système B.

Commencez par les automatisations à plus forte valeur, celles qui traitent les tâches manuelles les plus fréquentes ou les plus pénibles. Testez soigneusement avant de les activer pour tous les utilisateurs. Documentez ce que fait chaque automatisation et pourquoi. Prévoyez un interrupteur d'arrêt si une automatisation pose problème. Surveillez l'activité des automatisations pour détecter tout comportement inattendu.

Paramètres de notification

Construisez une stratégie de notification à trois niveaux. Les notifications critiques sont urgentes, exigent une action et partent immédiatement (nouvelle affectation, escalade). Les mises à jour importantes sont sensibles au temps et partent par lots, comme un récapitulatif quotidien. Les notifications d'information sont de faible priorité, et les utilisateurs peuvent choisir de les recevoir ou non (fil d'activité).

Configurez des paramètres de notification par défaut pour chaque rôle. Laissez les utilisateurs les personnaliser, car vous ne pouvez pas leur imposer des notifications dont ils ne veulent pas. Proposez le choix du canal (e-mail, dans l'application, notification mobile, Slack). Offrez un contrôle de la fréquence (immédiate, récapitulatif horaire, récapitulatif quotidien).

Évitez la lassitude liée aux notifications en ne prévenant pas les utilisateurs de ce qui ne les concerne pas. Regroupez les notifications peu prioritaires. Laissez les utilisateurs maîtriser ce qu'ils reçoivent. Testez le volume de notifications avec des usages réels avant la mise en production.

Image de marque et personnalisation

La personnalisation visuelle comprend le logo de l'entreprise et le favicon. Les couleurs de la marque et le thème. Un domaine personnalisé si votre produit le permet. L'image de marque des modèles d'e-mail.

Personnalisez pour les clients grands comptes attachés à la cohérence de leur marque. Pour les scénarios en marque blanche ou de revente, où votre marque ne doit pas apparaître. Pour les portails destinés aux clients, où l'image de marque joue sur la confiance et l'adoption.

Ne personnalisez pas lorsque cela retarde la mise en production pour des retouches de marque non essentielles. Ne personnalisez pas si le client n'y tient pas vraiment. Évitez les développements spécifiques complexes qui cassent à chaque mise à jour de votre produit.

Mise en place et test des intégrations

Connexions API et authentification

Processus de mise en place d'une intégration : identifier le type d'intégration (connecteur prêt à l'emploi ou API sur mesure). Obtenir les identifiants API auprès du client. Configurer l'authentification (clé API, OAuth, etc.). Créer la connexion dans votre plateforme. Tester l'authentification et la connexion. Configurer la correspondance des données. Tester la synchronisation. Activer en production.

Les méthodes d'authentification varient selon les exigences de sécurité. La clé API est simple : le client fournit la clé, vous configurez. OAuth est plus sûr : l'utilisateur autorise l'application, et le jeton est géré automatiquement. L'authentification basique repose sur un identifiant et un mot de passe, elle est moins sûre, à éviter si possible. L'authentification par certificat est complexe et correspond généralement à une exigence de sécurité des grands comptes.

Correspondance des données et alignement des champs

Processus de correspondance : identifier les champs sources dans le système du client. Les faire correspondre aux champs de destination de votre système. Gérer les écarts, comme les différences de noms de champs et les conversions de types de données. Définir des règles de transformation pour la concaténation, la mise en forme et les valeurs par défaut. Choisir le sens de la correspondance pour une synchronisation à sens unique ou bidirectionnelle.

Exemple de synchronisation des contacts CRM de Salesforce vers votre produit :

FirstName correspond directement à first_name. LastName correspond directement à last_name. Email correspond directement à email. AccountId demande une recherche dans la table Account pour obtenir company_id. LeadStatus nécessite une correspondance de valeurs : « Open » devient « Active » et « Closed » devient « Inactive ». Custom_Field__c correspond directement à industry.

Gérez les conflits en tranchant : que se passe-t-il si le même enregistrement est modifié dans les deux systèmes ? Quel système fait foi pour chaque champ ? Comment traiter les suppressions (suppression définitive, suppression logique, ignorée) ?

Test des intégrations

Les scénarios de test couvrent les bases : créer un enregistrement dans le système source et vérifier sa création dans le système de destination. Modifier un enregistrement dans la source et vérifier la mise à jour dans la destination. Supprimer un enregistrement et vérifier son traitement selon la configuration. Synchronisation en masse de plusieurs enregistrements. Gestion des erreurs pour des données invalides, un champ obligatoire manquant, les limites de débit de l'API.

Critères de validation : les données apparaissent correctement dans le système de destination. Les horodatages et les champs d'audit sont renseignés. Les enregistrements liés sont correctement associés. Aucune perte ni corruption de données. La synchronisation se termine dans un délai acceptable.

Gestion des erreurs et supervision

Anticipez les scénarios d'erreur : limites de débit de l'API dépassées. Expiration du jeton d'authentification. Données invalides qui échouent à la validation. Problèmes de connectivité réseau. Indisponibilité du système source ou de destination.

La stratégie de gestion des erreurs prévoit une logique de nouvelle tentative pour les échecs passagers. Une journalisation des erreurs pour le diagnostic. Une notification pour les erreurs critiques. Une file d'attente pour retraiter plus tard les enregistrements en échec. Une procédure d'intervention manuelle pour les erreurs irrécupérables.

Supervisez avec un dashboard de santé des intégrations. Suivez le taux de réussite et les échecs de synchronisation. Déclenchez une alerte quand les échecs dépassent un seuil. Réalisez des audits réguliers de l'exactitude des données synchronisées.

Exécution de la migration des données

Extraction et nettoyage des données

Extraction : exporter les données de l'ancien système. Vérifier que l'export est complet. Le stocker dans un emplacement sécurisé. Documenter la date d'export et le nombre d'enregistrements.

Exigences de nettoyage : supprimer les doublons. Uniformiser les formats des numéros de téléphone, des adresses et des dates. Renseigner les champs obligatoires ou les signaler pour revue par le client. Supprimer les données de test et les données parasites. Résoudre les problèmes de qualité identifiés pendant la découverte.

La responsabilité du nettoyage se partage entre l'éditeur et le client. L'éditeur peut gérer le nettoyage simple, comme la mise en forme et les doublons évidents. Le client doit gérer le nettoyage qui relève de la logique métier, par exemple décider quel doublon est le bon. Fixez dès le lancement des attentes claires sur qui fait quoi.

Transformation et correspondance des données

Les types de transformation comprennent la correspondance de champs, du champ source vers le champ de destination. La conversion de types de données, comme une chaîne vers un entier ou un changement de format de date. La correspondance de valeurs, comme « Y » vers « Yes » ou un code de statut vers un nom de statut. La concaténation, comme prénom plus nom vers nom complet. La séparation, comme une adresse complète vers ligne d'adresse 1, ville, région, code postal. La recherche et l'enrichissement pour ajouter les identifiants d'enregistrements liés ou compléter des données manquantes.

Documentez toute la logique de transformation. Faites valider par le client les décisions qui relèvent de la logique métier. Conservez une piste d'audit des modifications de données. Fournissez au client un échantillon avant/après pour validation.

Test et validation de la migration

Testez le processus de migration : migrer un petit jeu de données d'échantillon de 100 à 500 enregistrements. Valider l'exactitude et l'exhaustivité des données. Faire relire et approuver par le client. Corriger les problèmes découverts. Retester en cas de changements importants. Passer à la migration complète quand le test est concluant.

Contrôles de validation : le nombre d'enregistrements concorde entre la source et la destination. Aucune perte de données, tous les champs sont renseignés comme prévu. Les enregistrements liés sont correctement associés, avec les relations parent-enfant intactes. Le format des données est correct pour les dates, les nombres et les textes. Les caractères spéciaux et l'encodage sont bien gérés.

Pour la validation par le client, vous devez lui donner accès aux données de test. Fournissez des critères de validation précis. Obtenez une approbation écrite avant la migration complète. N'avancez pas tant que des problèmes restent non résolus.

Planification et exécution de la bascule

La migration en une fois (big-bang) migre toutes les données d'un coup. L'ancien système est arrêté. Tous les utilisateurs passent simultanément au nouveau système. Réservez-la aux petits jeux de données, aux données propres et aux fenêtres de migration courtes.

La migration progressive migre les données par lots, par période, par service ou par type d'enregistrement. L'ancien et le nouveau système fonctionnent temporairement en parallèle. La migration des utilisateurs se fait graduellement. Réservez-la aux gros volumes, aux migrations complexes et à la limitation des risques.

Checklist de bascule : figer les modifications dans l'ancien système ou documenter la stratégie de synchronisation. Lancer la migration complète des données. Valider la réussite de la migration. Activer les intégrations. Activer les comptes utilisateurs. Annoncer la mise en production aux utilisateurs. Surveiller les incidents pendant les 24 à 48 premières heures.

Le plan de retour arrière répond à des questions essentielles : que se passe-t-il si la migration échoue de façon catastrophique ? Pouvez-vous recharger les données et recommencer ? Comment revenir à l'ancien système si nécessaire ? Ne passez pas en production sans plan de retour arrière pour les systèmes critiques.

Tests et validation

Checklist de vérification de la configuration

Comptes et utilisateurs : tous les utilisateurs sont créés avec les bons rôles. Le SSO fonctionne, le cas échéant. Les permissions respectent les exigences du client. Les connexions des utilisateurs de test réussissent.

Workflows et automatisations : les processus métier sont correctement configurés. Les règles d'automatisation se déclenchent comme prévu. Les notifications sont envoyées de façon appropriée. Aucun comportement inattendu ni erreur.

Intégrations : toutes les intégrations sont connectées et authentifiées. Les données se synchronisent de façon bidirectionnelle comme configuré. Aucune erreur ni échec de synchronisation. La correspondance des données est correcte et complète.

Migration des données : toutes les données sont migrées avec succès. Le nombre d'enregistrements correspond à la source. La qualité des données répond aux attentes. Le client a validé un échantillon de données.

Image de marque et personnalisation : le logo et l'identité visuelle sont appliqués. Les champs personnalisés sont créés et configurés. Les rapports et les dashboards sont en place.

Recette utilisateur (UAT)

L'UAT vérifie que le système configuré répond aux exigences du client et fonctionne pour ses cas d'usage réels.

Processus d'UAT : créer un plan de test UAT avec les contributions du client. Définir des scénarios de test couvrant les workflows clés. Désigner des utilisateurs du client pour exécuter les tests. Documenter les résultats et les problèmes. Corriger les problèmes critiques avant la mise en production. Obtenir la validation écrite de l'UAT par le client.

Exemples de scénarios d'UAT : l'utilisateur se connecte avec succès via le SSO. L'utilisateur soumet une facture, le manager reçoit la notification et la valide. La facture validée se synchronise avec le système comptable. L'administrateur crée un nouvel utilisateur et lui attribue des permissions. Le manager lance un rapport montrant l'état des factures de son équipe.

La gestion des problèmes d'UAT hiérarchise les corrections. Les problèmes critiques signifient que le système ne fonctionne pas, bloquent la mise en production et doivent être corrigés. Les problèmes élevés sont majeurs mais avec un contournement possible : à corriger avant la mise en production ou peu après. Les problèmes moyens sont des désagréments non bloquants, à corriger en phase 2. Les problèmes faibles relèvent du confort ou de l'esthétique et vont au backlog.

Tests de performance et de charge

Les tests de performance comptent quand la base d'utilisateurs est importante, avec des centaines ou des milliers d'utilisateurs simultanés. Quand le traitement de données est à gros volume. Quand les workflows sont en temps réel ou sensibles au temps. Quand le client a des SLA de performance précis.

Scénarios de test de performance : charge d'utilisateurs simultanés, par exemple 500 utilisateurs connectés en même temps. Opérations de données en masse, comme l'import de 100 000 enregistrements. Génération de rapports sur de gros jeux de données. Débit de l'API pour les intégrations.

Critères d'acceptation : temps de chargement des pages inférieur à X secondes. Génération des rapports en moins de X minutes. Temps de réponse de l'API conformes au SLA. Système stable sous la charge attendue.

Validation de la sécurité

Checklist de sécurité : SSO correctement configuré et testé avec de vrais utilisateurs. MFA activé si nécessaire. Permissions appliquant le principe du moindre privilège. Données sensibles chiffrées en transit et au repos. Journalisation d'audit activée pour les actions sensibles. Accès API restreint aux adresses IP autorisées si nécessaire. Politiques de conservation des données configurées selon les exigences de conformité.

La revue de sécurité peut inclure une validation par l'équipe sécurité du client. Des tests d'intrusion pour les environnements à haute sécurité. Une revue des certifications de conformité. Documentez les contrôles de sécurité mis en place.

Documentation de la configuration

Documentation de l'existant (as-built)

Documentez la structure du compte et l'organisation. Les rôles des utilisateurs et le modèle de permissions. Les configurations de workflows et les règles métier. Les champs personnalisés et leur objectif. Les règles d'automatisation et les déclencheurs. Les correspondances d'intégration et les règles de synchronisation. Les décisions de migration des données et les transformations. L'image de marque et les personnalisations appliquées.

Cela sert au transfert de connaissances vers l'équipe d'administration du client. De référence pour les futures modifications de configuration. De base de diagnostic quand des problèmes surviennent. De piste d'audit pour la conformité. De support de formation pour les nouveaux administrateurs.

Journal des décisions de configuration

Documentez pourquoi les décisions de configuration ont été prises, pas seulement ce qui a été configuré.

Exemple : décision de fixer le seuil de validation des factures à 5 000 $. Justification : l'équipe finance a demandé de concilier contrôle et efficacité. Date : 2026-02-15. Approuvé par : le CFO.

Autre exemple : décision d'une synchronisation bidirectionnelle pour les contacts, à sens unique pour les comptes. Justification : Salesforce est le système de référence pour les comptes, mais les contacts peuvent naître dans l'un ou l'autre système. Date : 2026-02-18. Approuvé par : le directeur IT.

Quand quelqu'un demandera six mois plus tard « Pourquoi l'avons-nous configuré ainsi ? », vous aurez la réponse.

Création du guide d'administration

Contenu du guide d'administration : comment ajouter ou supprimer des utilisateurs et attribuer des rôles. Comment modifier les workflows et les règles métier. Comment créer des champs ou des objets personnalisés. Comment diagnostiquer les problèmes courants. Comment accéder aux rapports et les interpréter. Qui contacter pour le support éditeur. Bonnes pratiques d'administration au quotidien.

Les formats possibles : une documentation écrite dans Google Docs, Confluence ou un centre d'aide. Des tutoriels vidéo avec Loom ou un enregistrement d'écran. Une session de formation en direct avec enregistrement. Une combinaison de documentation et de vidéo.

Processus de gestion du changement

Les changements après la mise en production demandent un processus. Qui peut demander des modifications de configuration ? Quel est le processus de validation ? Comment les changements sont-ils testés avant le déploiement ? Comment les utilisateurs sont-ils informés des changements ? Comment la documentation de configuration est-elle mise à jour ?

Mettez ce processus en place dès le départ pour que les changements ne tournent pas à la pagaille.

L'essentiel à retenir

La création et la configuration des comptes ne sont pas une charge administrative. C'est le socle technique qui détermine si votre client obtiendra rapidement de la valeur et passera à l'échelle sans accroc, ou s'il subira frictions, contournements et, au bout du compte, le churn.

Les équipes qui expédient la configuration pour « mettre les utilisateurs plus vite dans le produit » créent des problèmes qui prennent des mois à corriger et qui plombent durablement l'adoption.

Les équipes qui investissent dans une configuration soignée et rigoureuse bâtissent un socle stable qui favorise une adoption rapide, une expansion fluide et une réussite durable.

Le travail est minutieux et méthodique. Le bénéfice est considérable : des clients qui obtiennent de la valeur plus vite, adoptent plus en profondeur, développent leur usage plus tôt et restent plus longtemps.

Posez le bon socle, et tout le reste devient plus facile.

---

Prêt à construire votre processus de configuration technique ? Explorez la planification de l'implémentation, les programmes de formation client et les critères de fin d'onboarding.

En savoir plus :

• Bonnes pratiques de la réunion de lancement
• Stack technologique post-vente
• Optimisation du time to value