Un CRM métier en trois jours : PACE à l'épreuve d'un vrai projet

Dans l’article de présentation de PACE, nous mettions en garde contre les promesses du type « un module en trois jours » : elles concernent presque toujours un projet neuf, à périmètre figé, avec un décideur unique et disponible.

Fin octobre, nous avons justement eu un projet qui cochait toutes ces cases. L’occasion de mesurer ce que PACE donne quand toutes les conditions sont réunies.

Le besoin

Notre client, une agence de communication éditrice d’un magazine, avait besoin d’un CRM commercial sur mesure pour sa petite équipe de commerciaux :

• gestion des contacts et de leurs interlocuteurs ;
• funnel commercial en kanban ;
• rendez-vous, actions commerciales et relances ;
• contrats ;
• tableau de bord avec graphiques, funnel en entonnoir et comparaison avec l’année précédente ;
• connexion avec les comptes Google de l’entreprise.

Un besoin clair, quatre utilisateurs, un décideur identifié, aucune intégration lourde avec un SI existant : le cas d’école pour PACE.

Prototyper, puis aligner

Le besoin avait d’abord pris forme dans un prototype cliquable. Conformément à PACE, ce prototype n’a pas été recyclé : il a été analysé, puis traduit en écrit.

Notre agent Product Owner a produit, à partir de cette analyse :

• les user stories du MVP, découpées en lots ;
• leurs critères d’acceptation en Gherkin, un fichier .feature par fonctionnalité (contacts, funnel, rendez-vous, actions, tableau de bord, authentification…) ;
• et un fichier qui compte autant que les autres : la liste des ambiguïtés, chacune soumise au client avec une proposition de réponse.

C’est l’étape Aligner : pas de spec figée, pas d’industrialisation.

Construire : trois jours, une soixantaine de merge requests

Une fois la spec figée, la construction a suivi un rythme soutenu :

• Jour 1 : spécifications Gherkin du MVP, puis fondations techniques, avec une application « hello world » qui traverse toute la chaîne de bout en bout (frontend, API, base, CI) ;
• Jour 2 : les lots fonctionnels, avec gestion des contacts, funnel kanban, rendez-vous, actions et relances, tableau de bord, authentification Google, gestion des commerciaux et des rôles ;
• Jour 3 : enrichissements et finitions, avec modales d’édition, design aux couleurs du client, fiche contact complète, contrats, graphiques du tableau de bord, qualification automatique des contacts, puis conteneurisation et infrastructure Terraform.

Au total, une soixantaine de merge requests, chacune liée à un ticket, chacune passée par la CI et par la revue avant fusion. Un ticket = une MR = un lot testable.

La stack retenue est volontairement classique : SvelteKit pour le frontend, NestJS et Prisma sur PostgreSQL pour l’API, documentée en Swagger, et une authentification Google OIDC limitée aux domaines de l’entreprise.

Une infrastructure taillée pour quatre utilisateurs

Un point mérite d’être souligné, car il illustre la différence entre « générer du code » et « livrer un produit ». La première version de l’infrastructure était correcte… mais surdimensionnée pour quatre utilisateurs.

Après arbitrage avec le client, elle a été revue pour le coût :

• conteneurs Scaleway Serverless avec scale-to-zero : l’application ne consomme rien quand personne ne l’utilise ;
• base PostgreSQL serverless à la place d’une instance managée permanente ;
• un environnement peut être éteint sans perdre ses données.

Avec en contrepartie, documentée noir sur blanc, la latence de réveil au premier accès. C’est un choix d’architecture assumé, pas un oubli.

Ce qui a fait la différence

Ce projet n’a pas été rapide parce que l’IA code vite. Il a été rapide parce que toute la chaîne l’était :

1. Un décideur disponible et réactif, qui a tranché les ambiguïtés au fil de l’eau.
2. Une spec écrite avant le code : les agents ne travaillaient que sur des stories figées, jamais sur une conversation.
3. Un socle posé en premier : la CI et le déploiement fonctionnaient avant la première fonctionnalité.
4. Des lots petits et indépendants, faciles à relire et à fusionner.
5. Des humains aux commandes : chaque arbitrage de périmètre ou de coût est resté une décision humaine.

Ce que ça ne prouve pas

Soyons honnêtes : ce projet est le meilleur cas possible. Un projet neuf, sans dette, sans intégration, avec une poignée d’utilisateurs et un décideur unique.

Sur un produit existant, avec plusieurs interlocuteurs et des intégrations SI, les délais restent dominés par la décision et la recette, pas par le code. C’est exactement ce que montrent nos chiffres sur deux produits au long cours.

La vraie leçon n’est donc pas « un CRM en trois jours », mais celle-ci : quand la décision et la spec suivent le rythme, les agents tiennent la cadence.

Vous avez un module métier bien délimité et un décideur disponible ? Parlons-en.