Pourquoi nous avons construit LeadGrid comme une seule API pour deux pipelines
La plupart des équipes growth utilisent un CRM et un ATS pour le même mouvement. Voilà ce qui s'effondre quand tu modélises sales et recrutement sur un seul modèle de données — et pourquoi on l'a rendu programmable par défaut.
Toutes les équipes growth avec lesquelles j'ai travaillé font la même chose deux fois. Sales a un CRM. Le recrutement a un ATS. Même forme de pipeline — entrée, qualification, progression, closing — mais sur deux stacks qui ne se parlent pas.
On a construit LeadGrid parce que cette séparation est un choix, pas une contrainte.
Le modèle de données est le même
Un lead et un candidat sont tous les deux des personnes qui avancent dans des étapes. Donne-leur un nom, une étape, une deadline, un responsable, un ensemble de notes — et tu as décrit les deux. Les verbes sont identiques : créer, assigner, faire avancer, commenter, clore.
L'industrie a construit deux catégories de produits autour de ça parce que c'était profitable, pas parce que le travail sous-jacent est différent. Les équipes se retrouvent à payer deux fournisseurs, intégrer deux APIs, se former sur deux interfaces, et réconcilier deux sources de vérité — pour suivre la même chose deux fois.
Ce qui s'effondre quand tu unifie
Faire tourner une seule plateforme pour les deux pipelines produit trois effets concrets :
- Les transferts n'échouent plus. Sales promet la livraison. Le recrutement trouve les personnes qui livrent. Quand les deux regardent le même grid, les escalades se passent avant que le candidat parte ou que le deal glisse.
- Le coût des outils est divisé par deux. Un seul workspace, une seule ligne de facturation, un seul modèle de permissions. Sales et recrutement arrêtent de se disputer sur quel outil fait foi — c'est le même.
- Le reporting devient honnête. Time-to-hire et time-to-close vivent dans la même base de données. Tu peux enfin répondre à la question « est-ce qu'on a raté ce deal parce qu'on n'avait pas la bonne personne ? » sans passer par un spreadsheet.
API-first, pas API en arrière-pensée
L'autre choix délibéré : chaque action que fait l'interface est un appel REST. Créer un dossier, changer d'étape, ajouter une note, assigner un membre — tout est scriptable, tout est documenté sur /docs/api.
Ça devrait être la norme, et pourtant : la plupart des CRMs réservent leurs meilleures fonctionnalités aux tiers supérieurs, enveloppent l'API dans des rate limits conçues pour te pousser vers les professional services, ou refusent de documenter les webhooks. On voulait l'inverse : l'API est le produit, l'interface est juste un moyen pratique de l'utiliser.
La conséquence concrète : tes automatisations se moquent que quelque chose soit un lead ou un candidat. Tu écris une intégration une fois, et elle fonctionne sur les deux pipelines. Claude, n8n, Zapier, ton propre backend — même forme d'endpoint, même auth, même schéma de webhook.
Gratuit pour toujours sur le plan gratuit
Une dernière chose. LeadGrid est gratuit pour toujours sur le plan gratuit — pas un essai de 14 jours, pas une promo limitée dans le temps. Tu peux faire tourner une vraie équipe dessus, construire de vrais pipelines, et ne jamais nous payer un centime. Les plans payants débloquent plus de seats, de dossiers actifs, de flows et de débit API quand tu dépasses les limites gratuites.
On préfère te voir construire sur la plateforme plutôt que regarder un compte à rebours s'écouler.