Commencez par l’objection, car elle est justifiée. Canny et Productboard lisent aujourd’hui les mêmes sources. L’Autopilot de Canny extrait du feedback depuis Zendesk, Intercom, Slack, Gong, Help Scout, Freshdesk, Zoom et tl;dv, plus les avis publics sur G2, Capterra, Trustpilot, l’App Store et Google Play. Productboard ingère lui aussi Zendesk, Intercom, Slack, Gong, G2, l’App Store et Google Play. Les deux regroupent ce qu’ils trouvent avec de l’AI et les deux dédupliquent. Acheter les deux ressemble à acheter deux fois le même moteur d’ingestion.
La partie qui ne se recoupe pas est la raison d’être de ce stack. Canny fait tourner un board sur lequel vos clients se connectent, publient et votent, ainsi qu’un changelog qui prévient chaque votant du moment où sa demande a été livrée. Le Portal de Productboard publie une roadmap : c’est une surface de diffusion, pas une communauté de vote. Productboard, en échange, détient l’appareil de priorisation — scoring contre des objectifs, définition des features et passage de relais vers l’engineering. Un outil est l’endroit où les clients débattent de ce qui compte. L’autre est l’endroit où votre équipe produit décide. Si vous n’avez besoin que de l’un des deux, achetez-en un seul, et cette page n’est pas pour vous.
Ce que fait chaque outil ici
Zendesk est la source de volume, pas le système de feedback. La plupart des demandes de features arrivent en deuxième paragraphe d’un ticket de support qui parle d’autre chose, et elles y meurent. Le rôle de Zendesk dans ce stack est de continuer à exister : l’agent résout le ticket et ne change rien à son workflow.
Canny est la couche côté client et le point de déduplication. Autopilot lit la conversation Zendesk, extrait la demande, la fusionne avec un post existant s’il y en a un, et la classe dans une zone produit. Le board public est l’endroit où la demande devient visible et comptable, et le changelog est la façon dont la boucle se ferme.
Productboard est la couche de classement interne. Il ingère sa propre copie des conversations de support et de vente, les rattache à des features, note ces features contre des objectifs et pousse le travail engagé vers Jira, Azure DevOps, GitHub, Trello ou Shortcut. Spark est la couche AI par-dessus tout cela et elle est incluse dans tous les plans, y compris le gratuit.
Slack est l’endroit où la boucle devient visible pour des personnes qui n’ouvriront ni l’un ni l’autre outil. Canny publie des notifications pour les nouveaux posts, les commentaires, les paliers de votes et les changements de statut ; par ailleurs, Canny comme Productboard traitent Slack comme une source de capture, si bien qu’une demande tapée dans #customer-feedback ne s’évapore pas.
Les passages de relais
- Un ticket arrive dans Zendesk avec une demande de feature → l’Autopilot de Canny la capture, la déduplique contre les posts existants et la classe dans une zone produit.
- La demande apparaît sur le board Canny → d’autres clients votent ; les paliers de votes et les changements de statut partent vers Slack.
- Un post atteint le seuil que vous avez fixé → il est poussé vers Jira ou Linear avec synchronisation de statut dans les deux sens.
- Productboard ingère directement les mêmes conversations Zendesk et Gong, les rattache à des features et les priorise contre des objectifs.
- Le travail est livré → le statut Jira ou Linear se resynchronise vers le post Canny → le changelog Canny notifie chaque client ayant voté.
L’étape 4 est l’endroit où ce stack a un trou, et prétendre le contraire rendrait le reste de la page inutile. Canny et Productboard n’ont aucune intégration native, dans aucun sens. L’annuaire d’intégrations de Canny ne liste pas Productboard, et celui de Productboard ne liste pas Canny. Vérifié le 16 août 2026.
La parade consiste à cesser de vouloir les relier directement et à faire de l’issue tracker la colonne vertébrale commune. Les deux outils se synchronisent nativement avec Jira, et les deux se rattachent au même issue, de sorte qu’une clé Jira devient la jointure entre le post public et la feature interne. Les alternatives sont pires : un pont Zapier ou Make que vous maintenez désormais, ou l’API de Canny contre celle de Productboard, ce qui donne au troisième mois une petite intégration interne sans propriétaire.
Base de coûts
Vérifié le 16 août 2026. Prenez une équipe de 8 agents de support et 4 personnes qui doivent écrire dans l’outil de roadmap.
Une configuration sobre : Zendesk Suite Team à $55/agent/mois en annuel ($440), Canny Pro à $79/mois facturé à l’année et Productboard Plus à $19/maker/mois en annuel ($76). Cela fait $595/mois, environ $7 140/an.
Une plus fournie : Zendesk Suite Professional à $115/agent/mois ($920), Canny Pro à $79, Productboard Business à $59/maker/mois en annuel avec un minimum de 2 makers ($236). Cela fait $1 235/mois, environ $14 820/an. L’add-on Copilot de Zendesk coûte $50/agent/mois de plus à partir de Professional, et Zendesk facture ses agents AI à la résolution automatisée plutôt qu’au siège.
La couche feedback représente environ un quart de la facture dans les deux configurations. Le nombre de sièges de support fixe le reste, ce qu’il vaut mieux savoir avant que la négociation ne parte chez le mauvais fournisseur.
Deux détails de facturation décident si ces chiffres tiennent. Canny ne facture pas au siège d’équipe : Free couvre 25 tracked users et 5 managers, Pro couvre 100 tracked users ou plus et 10 managers, et Business démarre à 5 000. Ce qui vous fait changer de palier, c’est la croissance du nombre d’utilisateurs finaux suivis, pas celle de votre équipe. Productboard compte des crédits AI par maker et par mois : 50 en Free, 250 en Plus, 500 en Business, 800 plus 1 500 crédits de base en Enterprise. Vérifiez la consommation de crédits pendant un essai avant de dimensionner le nombre de makers, car Spark est dans tous les plans et ce sont les crédits qui le rationnent réellement.
Variantes
Retirez Canny quand le board n’est pas public. Si les clients ne voient ni ne votent jamais les demandes, la moitié non recouvrante de Canny disparaît et le Portal de Productboard couvre la publication de la roadmap. Cela économise environ $948/an et supprime la couture du connecteur. La règle : si vous ne pouvez pas nommer les clients qui vont se connecter et voter, vous achetez un moteur de déduplication que vous avez déjà.
Retirez Productboard quand l’équipe est petite. En dessous d’une dizaine de personnes, la priorisation tient dans Jira ou Linear avec un champ de scoring, et Canny plus l’issue tracker constitue toute la boucle.
Remplacez Zendesk par Intercom ou Pylon. Canny comme Productboard ingèrent Intercom nativement, donc les passages de relais survivent intacts à la substitution.
Ce que ce stack ne remplace pas
Il ne vous dit pas ce que les clients ont fait, seulement ce qu’ils ont demandé. Le comportement relève du product adoption stack. Il ne défléchit pas les tickets : c’est le rôle de l’AI support agent stack. Ce n’est pas une pratique de discovery : le décompte des votes mesure l’enthousiasme des clients qui prennent la peine de voter, ce qui corrèle davantage avec le niveau sonore d’un segment qu’avec le chiffre d’affaires qu’il porte. Et ce n’est pas un système de health ou de renouvellement CS.
Deux points de vigilance avec leur parade. Les deux outils ingérant Zendesk indépendamment produisent deux regroupements différents des mêmes tickets, et la première fois que le PM et le CS apportent des décomptes différents de la même demande à la même réunion, la confiance dans les deux chiffres est perdue ; la parade consiste à donner à chaque source un seul système de référence, en laissant Canny propriétaire de tout ce qui est visible par le client et en pointant Productboard vers les calls commerciaux et les notes internes. Productboard est en plein pivot — Hubert Palan a annoncé le 15 avril 2026 que l’entreprise passait en AI-only et se séparait de plus de 30 % de l’équipe, en se reconstruisant autour de Spark ; la parade consiste à conserver les verbatims bruts dans Canny et Zendesk, où vous pouvez les exporter, et à traiter Productboard comme une couche de classement au-dessus d’un corpus qu’il ne détient pas seul.
Quand ce stack est le bon choix
Choisissez-le quand vous avez assez de clients pour qu’un board public reçoive de vrais votes, un volume de support assez élevé pour que les demandes s’enterrent dans les tickets, un PM et un responsable CS qui divergent aujourd’hui sur les priorités sans liste classée commune, et quelqu’un qui tiendra réellement le changelog.
Passez votre chemin quand votre nombre de clients est assez faible pour simplement les appeler — un board de vote réparti sur 30 comptes enterprise produit du bruit et un mandat factice — ou quand personne ne porte la boucle. Un board public qui affiche une demande « à l’étude » pendant deux ans est pire que de n’en avoir jamais ouvert, car c’est une trace durable, indexée et visible par le client de ce à quoi vous ne répondez pas.