Deux pipelines, un goulot d'étranglement
La plupart des scale-ups font tourner leur Sales et leur recrutement sur deux stacks qui ne se parlent jamais. Un seul hiring manager devient simultanément le goulot d'étranglement des deux pipelines.
Un vendredi après-midi, dans presque chaque scale-up avec lequel on travaille, deux choses échouent en même temps dans le même bâtiment — et personne ne réalise que c'est en fait le même problème. Un lead enterprise solide s'échappe parce que l'AE attend que le hiring manager confirme la capacité avant de s'engager sur une échéance. Deux étages plus bas, un ingénieur senior que la recruteuse a soigneusement suivi pendant trois semaines se fait silencieux, parce que ce même hiring manager n'a pas rappelé pour l'entretien de calibration. Le lead fuit. Le candidat refroidit. Le lundi matin, les deux équipes rapportent la perte dans leur propre standup, sur leur propre board, avec leur propre explication.
Ce ne sont pas deux problèmes distincts. C'est un seul problème, vu deux fois, par des équipes qui ne peuvent pas se voir.
La forme est identique, les stacks ne le sont pas
Chaque scale-up au-delà d'une certaine taille fait tourner deux processus qui se ressemblent sur le papier. Sales a des leads qui passent de qualified à discovery, puis à proposal, puis à close. Le recrutement a des candidat(e)s qui passent de sourced à screen, puis à interview, puis à offer. Même forme de pipeline, mêmes étapes dans l'esprit, même modèle d'ownership, même notion de last-touch et next-touch. Câble l'un sur HubSpot ou Pipedrive, l'autre sur Greenhouse ou Workable — et tu obtiens deux processus qui ne se voient jamais. Les personnes qui bloquent l'un bloquent souvent l'autre. Le contexte qui compte dans l'un compte souvent dans l'autre. Aucun outil ne le sait.
Les données sont déjà inconfortables
Le coût structurel de la fragmentation est quantifié. Un récent benchmark Gartner Sales Operations a constaté que les équipes revenue operations supportent désormais couramment cinq groupes ou plus et passent 68 % de leur temps sur des tâches hors relation client. Les deux tiers de la bande passante ops partent en coordination, en colle entre outils, en réconciliation, et à décoder lentement ce qu'un système différent voulait dire en changeant un statut. Et ça, avant même que quelqu'un demande si les deux processus adjacents dans ton entreprise — Sales et recrutement — partagent ne serait-ce qu'une définition d'étape.
Côté candidat(e)s, la fuite est plus rapide et plus visible. Les analyses sectorielles sur le processus de recrutement en 2025 pointent une dynamique sans détour : les meilleurs candidats quittent le marché en environ 10 jours, et le taux d'abandon des candidatures avoisine 60 % quand le processus traîne. Quand Sales obtient la réponse commerciale dont il a besoin et que le recrutement attend encore, le candidat a déjà dit oui à quelqu'un d'autre. Ton AE ne le sait pas. Ta recruteuse le sait, mais n'a nulle part où le signaler de façon visible pour l'AE.
L'inverse prouve l'argument. HubSpot Research a montré que quand Sales et Customer Success partagent un cadre opérationnel commun, la rétention grimpe de 36 % et les taux de closing de 38 %. La leçon ne porte pas spécifiquement sur le CS — elle porte sur la proximité. Deux équipes qui travaillent la même relation client performent radicalement mieux quand elles peuvent se voir. Il n'existe pas encore de benchmark publié pour l'alignement Sales + recrutement, parce que presque personne ne l'a mesuré — mais le mécanisme est le même. La proximité récompensée une fois se récompense deux fois.
L'anatomie d'un échec de handoff
Chaque fuite de handoff qu'on a tracée dans un scale-up se ramène à l'une de trois mécaniques.
La première est l'ownership périmé. Un lead ou un(e) candidat(e) a un nom accolé. Cette personne a entre-temps changé d'équipe, pris des vacances, ou s'est discrètement désengagée du compte. Le record n'est pas délibérément faux. Il est faux parce que rien dans le stack n'a jamais forcé une mise à jour. Sur un stack à un seul processus, c'est douloureux. Sur deux processus qui se bloquent mutuellement, c'est multiplicatif.
La deuxième est l'étape invisible. Un lead passe de « qualified » à « discovery » dans le CRM. La recruteuse ne le voit pas. Pourquoi le verrait-elle ? Le lead est un artefact Sales. Mais ce même compte a aussi un hiring manager qui est l'un des quatre décideurs du deal. Quand Sales déplace le record, le recrutement ne sait pas que la température vient de changer. Un entretien de calibration qui aurait pu avoir lieu cette semaine n'a finalement lieu que dans trois semaines — après que l'étape s'est déjà bloquée.
La troisième, et la plus coûteuse, est le goulot cross-motion. Une personne — généralement un hiring manager ou un VP Engineering — est simultanément la limite de débit de deux pipelines différents. L'équipe Sales attend qu'elle valide les effectifs avant de pouvoir s'engager sur le périmètre. L'équipe recrutement attend qu'elle signe l'offre avant qu'un candidat accepte. Chaque équipe escalade séparément. Chaque équipe ajoute à la pile que cette même personne doit traiter. Si l'une des deux équipes avait vu la file d'attente de l'autre, elle aurait regroupé la conversation. Aucune ne l'a vue.
Ce que change vraiment un cockpit partagé
L'ownership devient un seul champ, pas deux. La même personne, inscrite comme owner, est reportée dans les deux processus pour les comptes où c'est la même personne. Les étapes deviennent lisibles d'une équipe à l'autre. Un lead qui passe à « proposal » signale le record de recrutement pour la même entreprise, parce que les rôles à pourvoir pour ce compte viennent de devenir urgents. Les goulots apparaissent comme des goulots, pas comme deux demandes de reprogrammation sans lien. Le hiring manager voit ce qui est en attente des deux côtés dans une seule vue et prend une décision au lieu d'être relancé deux fois.
C'est ce que ça veut dire de mettre deux pipelines dans une seule grille — et c'est la raison d'être de LeadGrid. Non pas parce que les équipes Sales sont fatiguées des CRMs et les équipes recrutement de leurs ATSes, même si c'est vrai dans les deux cas. Mais parce que le handoff qui casse un scale-up ne se trouve pas à l'intérieur de l'un ou l'autre outil — il se trouve entre les deux.
L'audit à faire lundi
Tu n'as pas besoin d'une nouvelle plateforme pour commencer. Tu dois trouver où tes handoffs fuient vraiment. Quelques choses à tester la première semaine, avec ce que tu as déjà.
Arrive lundi matin et liste tous les leads qui ont stagné la semaine dernière, ainsi que tous les candidat(e)s qui ont stagné la semaine dernière. Mets-les dans le même tableur, triés par la personne nommée qui attend quelque chose. Compte combien de fois la même personne apparaît dans les deux colonnes. Ce chiffre est ton taux de goulot cross-motion. Chez la plupart des scale-ups qu'on a accompagnés, il se situe entre 15 et 30 %. C'est 15 à 30 % de tes blocages qui ne sont ni un problème Sales ni un problème recrutement — c'est un problème de file d'attente.
Vérifie ensuite tes champs d'ownership. Pour chaque record actif dans les deux systèmes, demande-toi si la personne listée a répondu à des e-mails au cours des cinq derniers jours ouvrés. Le pourcentage qui échoue est ton taux d'ownership périmé. Tout ce qui dépasse 20 % signifie que le record te ment au moment où tu en as le plus besoin.
Enfin, prends un compte ouvert où l'entreprise est à la fois un deal et une cible de recrutement. Aligne le journal d'activité Sales et le journal d'activité recrutement côte à côte. Remarque chaque moment où une équipe aurait pu faire gagner une journée à l'autre. Cette liste, c'est ton déficit de handoff.
La solution, c'est une grille, pas un CRM plus gros
Si les revenus fuient à la jonction entre Sales et recrutement, ce n'est pas parce que ton CRM est mauvais ou ton ATS incorrect. C'est parce que ton processus est une seule chose et ton stack en est deux. La solution n'est pas un CRM plus grand. Ce n'est pas un ATS plus profond. C'est une grille qui montre les deux pipelines avec le même vocabulaire, le même champ owner, et la même notion de ce que signifie « bloqué ». Donne aux responsables ops une seule vue du processus — et le processus arrête de laisser tomber les gens par terre.