Vous avez déjà eu l'un de ces projets intimidants où on vous demande de construire un CRM personnalisé de zéro, et vous vous dites, « Bon, c'est impossible » ? J'ai eu ce moment il y a deux ans avec un client qui avait besoin de son CRM en seulement 14 semaines. Pas un délai habituel. Mais voilà : en utilisant notre guide en 5 phases, ce n'était pas seulement réalisable, mais étonnamment fluide. Stack Overflow et Postman étaient mes compagnons quotidiens. Et oui, j'ai appris plus d'une ou deux leçons en chemin.
Phase 1 : Découverte et délimitation du périmètre (semaines 1-2)
La plupart des projets CRM échouent avant qu'une seule ligne de code soit écrite. Je suis sérieux. L'échec se produit dans une salle de conférence, généralement autour d'un tableau blanc, quand tout le monde approuve de vagues exigences et que personne ne pose les questions inconfortables.
Avec ce projet particulier (une entreprise de logistique de taille moyenne à Birmingham, environ 80 employés), j'ai passé les deux premières semaines à faire presque rien d'autre qu'écouter. Des ateliers, des appels Zoom enregistrés, et un document Notion partagé où les parties prenantes pouvaient déverser chaque workflow que le CRM devait gérer. Le document a atteint 47 pages. Beaucoup d'entre eux étaient contradictoires. C'est en fait bien ; les contradictions dans un document de découverte sont gratuites ; les contradictions découvertes à la semaine 11 vous coûtent un sprint et une relation client.
Ce que vous cartographiez réellement
L'objectif en discovery n'est pas de capturer chaque fonctionnalité. C'est de cartographier les relations de données et les rôles utilisateurs qui façonneront chaque décision architecturale en aval. J'utilise Whimsical pour les diagrammes de flux à ce stade. Rapide, partageables, et les clients peuvent commenter sans avoir besoin d'un compte.data relationships and the user roles that will shape every architectural decision downstream. I use Whimsical for flow diagrams at this stage. Quick, shareable, and clients can comment without needing an account.
À la fin de la semaine 2, vous avez besoin de quatre livrables verrouillés :
- Une liste de fonctionnalités priorisée, divisée en buckets MVP et post-lancement
- Un aperçu entité-relation (pas un schéma complet encore, juste les noms : contacts, deals, pipelines, tasks)
- Des définitions de rôles utilisateurs avec des niveaux de permission écrits en anglais simple
- Un calendrier signé avec des jalons nommés, pas des phases vagues
Celui-ci est non-négociable. « Phase 2 terminée » ne signifie rien. « Import de contacts et accès basé sur les rôles en direct dans staging avant le jour 28 » signifie quelque chose.
---
Phase 2 : Décisions d'architecture et de tech stack (Semaine 3)
Une semaine. C'est tout ce que je donne à cette phase, parce que j'ai vu des équipes disparaître dans des débats architecturaux pendant un mois et ne rien livrer.
Pour ce projet, la stack était : Node.js avec Express sur le backend, PostgreSQL pour la base de données, React sur le front end, et le tout déployé sur Kubernetes géré par DigitalOcean. Nous avons utilisé Prisma comme ORM parce que le schéma allait évoluer rapidement et le workflow de migration de Prisma est vraiment bon pour ça.Node.js with Express on the backend, PostgreSQL for the database, React on the front end, and the whole thing deployed on DigitalOcean managed Kubernetes. We used Prisma as the ORM because the schema was going to evolve quickly and Prisma's migration workflow is genuinely good for that.
Honnêtement, la stack importe moins que ce que les gens pensent. Ce qui importe davantage, c'est :
- Est-ce que chaque développeur sur ce projet connaîtra cette stack sans une courbe d'apprentissage abrupte ?
- Est-ce que l'architecture supporte le modèle de permissions que vous avez mappé en Phase 1 ?
- Pouvez-vous ajouter un nouveau type d'entité (disons, « fournisseur ») à la semaine 10 sans réécrire la couche d'authentification ?
C'est sur ce troisième point que je me suis planté avant. En 2021, Seahawk Media avait un projet SaaS où on a ajouté la multi-tenancy à la semaine 9. Ça a pris quatre jours pour rétrofiter ce qui aurait dû être une décision au jour un. Jamais plus.
Pour l'authentification, je me rabats sur Auth0 à moins qu'il y ait une raison convaincante de ne pas le faire. Ça gère les cas limites (réinitialisations de mot de passe, MFA, connexion sociale) qui dévorent les développeurs juniors.Auth0 unless there's a compelling reason not to. It handles the edge cases (password resets, MFA, social login) that eat junior developers alive.
---
Phase 3 : Core Build Sprint (Semaines 4-9)
Six semaines. C'est la salle des machines. Et si votre scoping était solide, cette phase est en fait la partie la plus directe de tout le projet.
J'ai divisé cela en deux mini-sprints de trois semaines avec un examen interne strict au point médian.
Sprint A : Couche de données et API (Semaines 4-6)
Rien ne touche le front end tant que le contrat de l'API n'est pas accepté. Point final. Je documente chaque endpoint dans Postman avant d'écrire un contrôleur, ce qui semble fastidieux mais évite environ deux semaines de conversations « attendez, qu'est-ce que cet endpoint retourne ? » plus tard.Postman before writing a controller, which sounds tedious but saves about two weeks of "wait, what does this endpoint return?" conversations later.
Le schéma de la base de données reçoit sa première vraie révision ici. Pour les CRM, les tables qui sont toujours sous-estimées sont la table du journal d'activité et la table des champs personnalisés. Chaque client veut des champs personnalisés. Construire correctement une table custom_field_definitions flexible dès le premier jour, c'est environ quatre heures de travail. L'improviser en semaine 11 est un cauchemar.custom_field_definitions table properly from day one is about four hours of work. Improvising it in week 11 is a nightmare.
Sprint B : Front End et Workflows (Semaines 7-9)
React avec TanStack Query pour la gestion de l'état du serveur. J'ai essayé de me débrouiller avec useEffect simple et l'état local sur un projet plus petit en 2022. Je ne me ferai plus jamais ça, TanStack Query gère la mise en cache, le refetch en arrière-plan et les mises à jour optimistes d'une manière qui rend les interfaces CRM réactives sans effort surhumain.TanStack Query for server state management. I tried rolling with plain useEffect and local state on a smaller project in 2022. Never doing that to myself again, TanStack Query handles caching, background refetching, and optimistic updates in a way that makes CRM interfaces feel snappy without heroics.
Pour la couche de composants UI, nous avons utilisé shadcn/ui sur ce projet. Ce n'est pas une bibliothèque de composants au sens traditionnel ; vous possédez le code, ce qui signifie que vous pouvez vraiment le personnaliser sans combattre la bibliothèque. Pour un CRM avec une vue pipeline, un tableau de contacts et un tableau de tâches, cette flexibilité compte.shadcn/ui on this project. It's not a component library in the traditional sense; you own the code, which means you can actually customise it without fighting the library. For a CRM with a pipeline view, a contacts table, and a task board, that flexibility matters.
Une chose qui glisse systématiquement dans ce sprint : les états vides. Un CRM sans données a l'air cassé si vous n'avez pas conçu les écrans d'état zéro. Construisez-les tôt. Les clients font la démo aux stakeholders avec des bases de données vides et les premières impressions restent.empty states. A CRM with no data looks broken if you haven't designed for zero-state screens. Build them early. Clients demo to stakeholders with empty databases and first impressions stick.
---
Phase 4 : Intégrations et Migration de données (Semaines 10-11)
C'est là que la plupart des agences sous-évaluent et mal planifient. Je l'ai vu à chaque fois.
Le client logistique de Birmingham avait besoin d'intégrations avec sa configuration Xero existante et une instance Salesforce plus ancienne qu'il abandonnait. Deux semaines, ça semblait serré. C'était le cas, mais on a réussi parce qu'on avait défini les points d'intégration dès la Phase 3.Xero accounting setup and an older Salesforce instance they were migrating away from. Two weeks sounds tight. It was, but we made it because we'd stubbed the integration points back in Phase 3.
Pour la migration Salesforce spécifiquement, on a utilisé leur Bulk API 2.0 pour extraire les données, puis on les a passées dans un script Node qui mappait leur structure de champs à la nôtre. Le script a pris un jour à écrire et trois jours à itérer dessus parce que les données Salesforce ne sont presque jamais aussi propres que les clients le croient. Budgétisez le nettoyage des données. Toujours.Bulk API 2.0 to extract the data, then ran it through a Node script that mapped their field structure to ours. The script took a day to write and three days to iterate on because Salesforce data is almost never as clean as clients believe it is. Budget for data cleaning. Always.
Quelques points que je vérifie avant de déclarer une intégration « terminée » :
- Gestion des erreurs : que se passe-t-il quand l'API tiers est hors ligne ?
- Idempotence des webhooks : pouvez-vous traiter sans risque le même événement deux fois sans dupliquer les enregistrements ?
- Limites de débit : êtes-vous dans les limites sous une charge réaliste ?
La documentation des développeurs Xero est en fait correcte, pour ce que ça vaut. Le flux OAuth 2.0 est bien documenté et leur environnement sandbox fonctionne de manière fiable.Xero developer docs are actually decent, for what it's worth. The OAuth 2.0 flow is well documented and their sandbox environment works reliably.
---
Phase 5 : QA, Durcissement et Handover (Semaines 12-14)
Trois semaines pour le QA, ça semble généreux jusqu'au moment où tu les vis.
La semaine 12 est consacrée aux tests structurés. Je donne au client un tableau ClickUp avec chaque cas de test écrit sous forme de tâche, il teste, il marque, il joint une Loom si quelque chose ne fonctionne pas. Ça permet à de vrais utilisateurs de cliquer sur de vrais flux, ce qui découvre toujours des choses qu'un test menée par un développeur ne rattrape. Quelqu'un essayera de coller 4 000 caractères dans un champ « notes ». Quelqu'un importera un CSV avec des guillemets intelligents dedans. Tu veux trouver ça maintenant.ClickUp board with every test case written as a task, they test, they mark it, they attach a Loom if something breaks. This gets real users clicking real flows, which always uncovers things that a developer-run test misses. Someone will try to paste 4,000 characters into a "notes" field. Someone will import a CSV with smart quotes in it. You want to find this now.
La semaine 13 est le sprint de correction. Pas de nouvelles fonctionnalités. Corrections de bugs et optimisations de performance uniquement. Je lance Lighthouse sur chaque page clé. Je lance aussi des tests de charge k6 contre l'API, non pas parce que le client l'a demandé, mais parce que trouver une requête lente avec 50 utilisateurs simultanés en semaine 13 est mieux que la découvrir après le go-live.Lighthouse against every key page. I also run k6 load tests against the API, not because the client asked for it, but because finding a slow query under 50 concurrent users in week 13 beats finding it after go-live.
La semaine 14 est la passation et la préparation du go-live.
La documentation de passation que je produis couvre :
- Vue d'ensemble de l'infrastructure (ce qui tourne où, comment le scalabiliser)
- Procédure de sauvegarde et de restauration de base de données, testée et vérifiée
- Comment ajouter un nouveau rôle utilisateur sans toucher au code
- Les limitations connues et les éléments du backlog que nous avons reportés
C'est important, ce dernier point. Sois honnête sur ce qui n'a pas fait le cut. Les clients le respectent, et ça prépare la phase suivante du travail proprement plutôt que de laisser une dette non dite peser sur la relation.
Une dernière chose avant le lancement
Échelonnez-le. Nous avons fait un soft-launch auprès de 10 utilisateurs au jour 92, observé les logs pendant 48 heures via Datadog, puis ouvert l'accès à l'équipe complète de 80 personnes. Cette fenêtre de 48 heures a mis en évidence deux cas limites dans les transitions d'étapes du pipeline qui n'étaient pas apparus lors des tests. Rien de catastrophique, mais le genre de choses qui aurait généré 15 tickets de support dès le premier jour si nous étions allés à plein régime.Datadog, then opened it to the full 80-person team. That 48-hour window caught two edge cases in the pipeline stage transitions that hadn't shown up in testing. Nothing catastrophic, but the kind of thing that would have generated 15 support tickets on day one if we'd gone full-steam.
Le lancement n'est pas la fin. C'est juste le moment où commencent à arriver les données réelles de comportement utilisateur.
---
FAQ
Combien coûte typiquement un CRM personnalisé comme celui-ci ?
Honnêtement, ça varie énormément, mais un projet de 14 semaines au niveau de complexité ici avec une petite équipe (deux développeurs back-end, un développeur front-end, un chef de projet) coûte généralement entre £60 000 et £120 000 selon la complexité des intégrations et de la migration de données. Si vous voyez des devis sous £30 000 pour un build entièrement personnalisé, approfondissez vraiment ce qui est réellement construit par rapport à ce qui est configuré à partir d'un modèle existant.
Peut-on construire un CRM personnalisé sur WordPress ?
Vous pouvez, mais je ne le ferais pas pour plus d'environ 500 enregistrements ou 20 utilisateurs simultanés. La couche de données de WordPress n'est pas conçue pour les charges de travail CRM relationnelles. Chez Seahawk nous avons construit des couches de gestion de contacts sur WordPress pour des clients plus petits, mais pour quoi que ce soit de sérieux, un vrai back-end avec une base de données relationnelle est le bon choix.
Quelle est la plus grande erreur que commettent les équipes sur les builds de CRM ?
Sous-spécifier le modèle de permissions. Tout le monde se concentre sur les fonctionnalités et oublie qu'un CRM avec 80 utilisateurs a besoin d'une réponse nuancée à « qui peut voir quel deal ? » avant que tu écrives une seule route API. Ajouter le contrôle d'accès basé sur les rôles à la semaine 10 est douloureux d'une façon qu'il est difficile de décrire tant que tu ne l'as pas fait une fois.
Utilises-tu toujours exactement cette même stack technologique ?
Non. La stack que j'ai décrite a fonctionné pour l'équipe et les contraintes de ce projet. J'ai livré des CRM sur Laravel et Vue, sur Django et React, et une fois sur une configuration Next.js full-stack dont j'étais sceptique mais qui a en fait très bien fonctionné. Les principes architecturaux restent les mêmes. Les outils changent.
Au final, le projet CRM personnalisé n'a pas été qu'un défi, mais une révélation. Cette fenêtre étroite de 14 semaines ? Elle nous a forcés à innover, à nous adapter et à livrer. Il s'avère que les contraintes peuvent être un catalyseur de créativité. Qui aurait cru que les délais pouvaient nous enseigner tant de choses sur notre métier ? C'est des projets comme celui-ci qui me rappellent pourquoi j'ai cofondé Seahawk Media.