La plupart des équipes abordent cette conversation comme s'il s'agissait d'une question technique, mais je ne pense pas que ce soit le bon point de départ.
Quelle est la différence entre l'API seulement et le composant?
L'API seulement signifie que votre équipe construit elle-même l'expérience de paie front-end, tandis que Nmbr alimente l'infrastructure sous-jacente.
Le composant est une expérience de paie front-end préconstruite que vous pouvez intégrer à votre plateforme. Les cycles de paie, les rapports, les formulaires, les TD1, les paramètres de paie, les détails de paie des employés et d'autres éléments essentiels sont déjà en place. Vous pouvez personnaliser les polices, les couleurs et l'image de marque, l'intégrer derrière un onglet « Paie » et lancer un véritable produit de paie sur le marché beaucoup plus rapidement que si vous construisiez le tout à partir de zéro.
Je le décris généralement comme l'intégration de Stripe, mais pour la paie.
En bref : créez un onglet « Paie », intégrez le composant, harmonisez l'image de marque, et vous obtenez une expérience de paie fonctionnelle au sein de votre produit. La mise en garde importante est que ce n'est pas l'intégration complète – c'est seulement le front-end.
À quoi ressemble un composant de paie intégré prêt à l'emploi?
En pratique, le composant transforme un onglet de paie comme celui-ci :
En une expérience de paie fonctionnelle comme celle-ci :
Aujourd'hui, nous travaillons avec plus de 30 partenaires, y compris des plateformes à très grande distribution. Je le mentionne parce que nos clients qui utilisent uniquement le composant se retrouvent lors de démonstrations où leurs prospects disent : « Vos écrans de paie ressemblent beaucoup à ceux de telle ou telle entreprise. »
Ce n'est pas une mauvaise chose, car nous avons passé des années à concevoir le composant pour qu'il soit le meilleur de sa catégorie du point de vue fonctionnel et de l'expérience utilisateur. Cependant, personne ne veut que son produit semble interchangeable.
C'est là qu'interviennent les ressources et l'expertise.
Si votre équipe n'a jamais conçu de système de paie auparavant, soyez honnête quant à l'ampleur de la tâche. Pouvez-vous concevoir les cycles de paie, les rapports, les formulaires, les flux de configuration, les exceptions et les écrans spécifiques à la paie suffisamment bien pour qu'un véritable administrateur de paie y fasse confiance?
La plupart des partenaires devraient commencer avec le composant. Non pas parce que l'API seulement est une mauvaise approche. C'est juste que cela demande plus à votre équipe que ce que les gens attendent habituellement. Non seulement en termes de temps et de ressources, mais aussi en termes d'enjeux.
C'est la réponse honnête.
Pourquoi Nmbr a-t-il créé le composant de paie?
Lorsque nous avons lancé Nmbr, nous étions uniquement basés sur l'API. Cela signifiait que nous fournissions l'infrastructure dorsale : le moteur fiscal, les mouvements de fonds, le portail partenaire, les flux de travail de conformité et la couche API dont les partenaires avaient besoin pour construire une expérience de paie personnalisée par-dessus nos services.
Nos partenaires étaient responsables de la création de l'ensemble de l'interface utilisateur, des écrans de traitement de la paie aux formulaires TD1 à remplir et aux rapports.
Et honnêtement, beaucoup d'équipes ont eu des difficultés. Non pas parce que c'étaient de mauvaises équipes, mais parce que la paie est un domaine complexe.
Notre composant compte environ 87 écrans, allant de la page d'accueil de la paie à l'écran récapitulatif. Cela représente beaucoup de décisions produit avant même d'aborder le travail d'API. Il y a beaucoup de choses à faire correctement, surtout lorsqu'il s'agit de décider ce qui doit figurer dans la version un et ce qui peut attendre.
Certains de nos partenaires ont ignoré les écrans de prestations parce qu'ils desservaient des industries où les prestations semblaient rares. Puis, lors d'une démonstration, quelqu'un demandait où étaient configurées les déductions de prestations… ce n'est pas le meilleur moment pour réaliser qu'une hypothèse était erronée.
En tant que fournisseur de services de paie intégrés, nous réussissons lorsque nos partenaires intègrent réellement des clients de la paie à la plateforme. Nous offrons un soutien en matière de stratégie produit, d'ingénierie, de positionnement, de formation sur les ventes et l'expérience client, et plus encore, tout cela pour vous aider à lancer et à développer une entreprise de paie prospère. Mais rien de tout cela n'a d'importance si le produit qu'un client voit le jour de la démonstration semble incomplet.
Et lorsque votre équipe doit concevoir autant d'écrans, le lancement prend plus de temps.
Il y a deux risques : développer la mauvaise solution et prendre trop de temps pour apprendre que vous avez développé la mauvaise solution.
Avez-vous le temps, les ressources et l'expertise en matière de paie pour le construire correctement? Si ce n'est pas le cas, commencez par le composant, obtenez les commentaires de vrais clients et décidez ce qui vaut la peine d'être personnalisé plus tard.
Les partenaires qui ont opté pour l'API seulement avaient une bonne raison de le faire. Ils avaient de solides cultures produit et d'ingénierie, une vision claire de leur client et une marque pour laquelle une interface utilisateur tierce aurait semblé déplacée. Leurs cultures produit et d'ingénierie étaient axées sur la maîtrise des détails. Pour eux, l'utilisation d'une interface utilisateur tierce n'était pas compatible avec leur marque ou ce pour quoi leurs clients les connaissent. Ils avaient la conviction et les méthodologies pour bien faire les choses, et ils ont maintenant des produits de paie avec lesquels il est très difficile de rivaliser dans leurs secteurs d'activité.
« Wow », pourriez-vous penser. « Ce qu'ils ont construit est mieux que votre composant? »
Oui.
Non pas parce que leur interface utilisateur en fait plus que le composant. En fait, elle en fait beaucoup moins. Comme mentionné précédemment, notre composant compte 87 écrans. C'est beaucoup, mais nous l'avons conçu pour s'adapter à presque tous les cas d'utilisation.
D'un autre côté, pour nos clients qui utilisent uniquement l'API, tous étant dans le SaaS vertical, ils l'ont construit en pensant à leur avatar client. Si vous servez des restaurants et que l'expérience de paie parle le langage des restaurants, c'est important. Il en va de même pour la construction, les soins de santé, l'hôtellerie ou tout autre secteur vertical où la paie présente des points douloureux spécifiques à l'industrie. C'est pourquoi ils ont un taux d'adoption de la paie si élevé : leurs flux de travail ont été clairement conçus en fonction du fonctionnement des industries qu'ils desservent.
Mais le travail d'interface utilisateur pour la paie ne consiste pas seulement à créer des écrans. Vous devez comprendre les nuances de la paie, où les risques apparaissent, ce que font réellement les administrateurs de paie, quels flux de travail sont importants et ce qui doit être là dès le premier jour par rapport à plus tard. Vous avez également besoin des ressources de conception pour que le produit inspire confiance. La paie n'est pas l'endroit où les gens veulent avoir l'impression d'utiliser un produit à moitié terminé.
Si nous utilisons le composant, avons-nous terminé l'intégration?
Non. C'est probablement la chose la plus importante à comprendre.
Le composant vous fournit l'interface utilisateur pour la paie. Il ne rend pas la paie précieuse au sein de votre produit par lui-même.
Si un client se connecte à votre écran de paie et ne trouve aucun employé, taux de rémunération, heures travaillées, coordonnées bancaires des employés ou informations commerciales, vous n'avez pas ajouté beaucoup de valeur. Vous avez placé la paie à côté de votre produit et lui avez donné un endroit distinct pour saisir les données.
L'intégration de l'API est nécessaire dans tous les cas.
La différence est que, avec le composant, l'intégration se concentre davantage sur le mappage des données.
Quelles données de paie avez-vous déjà? Que vous manque-t-il? Quel système devrait gérer chaque champ?
C'est là que le composant vous offre des options. Peut-être que votre plateforme stocke déjà les profils d'employés, les heures, les taux, les départements et les emplacements. Intégrez cela à la paie. Si vous ne stockez pas encore la juridiction fiscale ou d'autres champs spécifiques à la paie, laissez le composant les recueillir pour l'instant.
Vous n'avez pas besoin de reconstruire tout votre produit autour de la paie dès le premier jour. Mais vous devez prendre la paie suffisamment au sérieux pour que le flux de données fonctionne, que la responsabilité soit claire et que les clients ne saisissent pas les mêmes informations à deux endroits.
Pourquoi la plupart des partenaires commencent-ils avec le composant?
Tout ce qui précède est important, mais la raison la plus simple est qu'ils veulent lancer leur produit.
De nombreux projets API-first peuvent sembler progresser pendant longtemps. L'équipe connecte les points de terminaison, mappe les données, gère les cas limites, s'occupe de l'authentification et prend des décisions techniques. Tout cela est important.
Mais six mois plus tard, quelqu'un demande : « Puis-je le voir? » Et la réponse est encore essentiellement non.
La preuve de concept est importante. Vous avez besoin de quelque chose que les gens peuvent voir. Même s'il ne s'agit au début que d'un collègue qui le parcourt, cela fait évoluer la discussion.
Les ventes peuvent le vendre. L'équipe produit peut le tester. La direction peut comprendre l'investissement. Les clients peuvent vous dire ce qui est réellement utile.
À ce jour, la plupart de nos partenaires utilisent le composant pour une partie ou la totalité de leur expérience de paie. Certains l'utilisent parce qu'ils veulent lancer rapidement. D'autres l'utilisent pour apprendre avant de personnaliser. Ensuite, ils arrivent sur le marché, les clients l'utilisent, et la conclusion est essentiellement : « C'est solide. » Peut-être qu'un prospect remarque que les écrans de paie semblent familiers. Évidemment, ce n'est pas idéal, mais c'est un problème beaucoup plus petit que de passer un an à reconstruire un flux de travail que les clients sont déjà heureux d'utiliser.
Quand devriez-vous opter pour l'API seulement?
L'API seulement a du sens lorsque vous avez une vraie raison de maîtriser l'expérience de paie, pas seulement une préférence. Un facteur majeur à cet égard est votre niveau de connaissances internes en matière de paie.
Si votre équipe connaît déjà la paie, comprend vos clients, dispose d'un leadership produit solide et de ressources en conception et en développement frontal, alors l'API seulement peut être la bonne décision. Cela prendra plus de temps, mais si vous vous investissez à fond, vous pouvez obtenir un meilleur produit parce que vous savez ce que vous essayez de construire, pourquoi c'est important et où votre produit doit être différent.
Il y a des partenaires pour qui c'est évident. Ils travaillent dans le domaine de la paie depuis des années. Ils ont utilisé tous les systèmes de paie. Ils savent ce qui est mal conçu. Ils savent où le processus actuel pose problème à leurs clients. Ils ne partent pas de zéro.
Dans ce cas, construire une plus grande partie de l'expérience vous-même peut avoir du sens.
L'autre raison est la différenciation. Si la paie est au cœur de votre stratégie produit, vous ne voudrez peut-être pas d'un flux de travail standard. Une plateforme de construction, par exemple, pourrait avoir besoin d'écrans de traitement de la paie qui affichent le coût des emplois, les syndicats, les primes de quart, les flux de travail saisonniers pour les relevés d'emploi (RE) ou d'autres détails qu'un écran de paie générique ne gérerait pas bien. Si ce flux de travail est l'une des raisons pour lesquelles les clients achètent votre produit, vous voulez probablement en maîtriser davantage.
Mais si vous choisissez l'API seulement parce que cela vous semble plus propre ou plus flexible, je serais prudent.
La flexibilité est excellente lorsque vous savez ce que vous voulez en faire. Mais si vous optez pour l'API seulement pour apprendre la paie de zéro, cela peut devenir coûteux rapidement. C'est parce que vous ne construisez pas seulement des écrans – vous prenez des décisions produit dans un domaine avec beaucoup de cas limites.
Vous essayez de choisir la bonne voie d'intégration?
Le meilleur chemin dépend de l'ampleur de l'expérience de paie que vous voulez que votre équipe maîtrise dès le premier jour. Nmbr peut vous aider à comparer les options API seulement, Composant et hybrides en fonction de vos objectifs produit, de la capacité de votre équipe et de votre calendrier de lancement.
Comment le calendrier devrait-il influencer la décision?
Le facteur temps modifie la réponse, car les lancements de services de paie sont généralement plus lents que prévu. Un lancement typique pourrait ressembler à ceci :
- Pilote : 1 à 3 clients pendant 30 à 60 jours
- Phase 2 : 5 à 10 clients pendant 30 à 60 jours supplémentaires
- Disponibilité générale : Une fois que le soutien, l'implémentation et le produit sont prêts à gérer un volume plus important
Pendant les phases initiales, vous recueillez les commentaires des clients, vous améliorez les processus et vous vous préparez à la disponibilité générale. Même lorsque vous atteignez la disponibilité générale (GA), selon vos ressources, vous pourriez ne pas avoir la capacité d'implémentation et de soutien nécessaire pour prendre en charge une vague de clients (à moins que vous ne vous appuyiez sur votre partenaire intégré, ce que nous aborderons dans un autre article).
En d'autres termes, le déploiement de la paie est généralement un processus lent. Vous voudrez peut-être créer le produit API-first parfait, mais si vous voulez atteindre la disponibilité générale cette année, une approche API seulement pourrait ne pas convenir au calendrier.
En ce qui concerne le calendrier, nous suggérons de travailler à rebours à partir de l'objectif. Si l'objectif est de lancer rapidement, de se positionner, de vendre et de tester le marché, le composant est généralement la solution recommandée. Si l'objectif est de créer un excellent produit de paie et que vous avez le temps et l'équipe, l'approche API seulement peut être judicieuse.
Aucune des deux approches n'est automatiquement meilleure. Elles résolvent des problèmes différents. Il suffit d'être honnête quant à celle que vous optimisez.
Pouvez-vous utiliser à la fois le composant et l'API?
Oui. En pratique, c'est là que la plupart des intégrations aboutissent. Commencez par le composant, puis utilisez l'API là où votre produit a une réelle raison d'être différent (par exemple, l'exemple de l'ARC de construction mentionné précédemment).
Vous pouvez commencer par le composant, effectuer une intégration backend approfondie, lancer un projet pilote, recueillir des commentaires, itérer, lancer le groupe suivant et continuer d'apprendre. Au fur et à mesure que vous apprenez, vous pouvez décider quelles parties de l'interface utilisateur valent la peine d'être gérées par vous-même.
Peut-être gérez-vous l'intégration des employés. Peut-être gérez-vous l'attribution des avantages sociaux. Peut-être gérez-vous les rapports. Peut-être gérez-vous la préparation des cycles de paie parce que votre plateforme dispose d'un contexte que le composant n'a pas.
Vous pouvez prendre en charge ces éléments et désactiver les actions connexes dans le composant.
Qu'en est-il de la sécurité avec l'iFrame?
Pour les banques, les grandes plateformes et les partenaires d'entreprise, la question de l'iFrame se pose rapidement.
C'est normal. La paie contient des données sensibles. Noms, adresses, NAS, coordonnées bancaires, dossiers d'employés et les informations nécessaires pour transférer de l'argent. Si vous intégrez la paie à votre plateforme, votre équipe de sécurité devrait se soucier de l'endroit d'où le composant est chargé, de la manière dont l'utilisateur est autorisé, de l'endroit où les données sont stockées et du contrôle que votre plateforme conserve sur le flux.
L'important est que le composant n'ait pas à fonctionner comme un script tiers aléatoire intégré à votre produit sans aucun contrôle. Pour les partenaires plus restrictifs, le composant peut être empaqueté et hébergé par le partenaire plutôt que d'être chargé directement depuis notre CDN. Dans ce modèle, l'expérience de paie reste au sein de votre plateforme, mais le paquet est servi depuis votre environnement. Cela est important pour les équipes qui ne veulent pas qu'un composant tiers se charge à distance chaque fois que la page s'ouvre.
L'iFrame fait toujours partie du fonctionnement du composant. Il maintient l'expérience de paie contenue, évite les conflits avec le code frontal de votre plateforme et permet à l'expérience spécifique à la paie d'évoluer sans que votre équipe n'ait à reconstruire chaque écran. Mais du point de vue de l'utilisateur, la paie reste au sein de votre plateforme. Ce n'est pas un lien de fournisseur qui prétend être une paie intégrée.
L'authentification fonctionne de la même manière. Votre plateforme authentifie l'utilisateur. Votre plateforme décide si cet utilisateur est autorisé à faire la demande. Ensuite, un jeton signé de courte durée est attaché à la demande afin que Nmbr puisse valider qu'elle provient de vous, qu'elle n'a pas été modifiée et qu'elle est toujours valide.
Cette distinction est importante, car nous ne cherchons pas à nous approprier votre session client. Nous validons des requêtes que votre plateforme a déjà autorisées.
Pour certains partenaires, les appels d'API peuvent également passer par un proxy contrôlé par le partenaire. Cela donne au partenaire plus d'observabilité et de contrôle. Il peut voir ce qui transite, appliquer ses propres modèles, et dans des environnements plus stricts, cela lui offre un disjoncteur : si quelque chose semble anormal, il peut couper la connexion de son côté. Tous les partenaires n'en ont pas besoin, mais pour les banques et les plateformes d'entreprise, cela peut faire partie de l'architecture.
Côté données, Nmbr détient les informations nécessaires pour gérer la paie, mais cela peut être structuré de manière à ce que le partenaire conserve la propriété et le contrôle. Pour les grandes organisations, cela peut inclure des options comme la location dédiée, les clés contrôlées par le partenaire et la résidence des données au Canada. La configuration exacte dépend des exigences du partenaire, mais l'idée est qu'il existe des modèles pour que cela fonctionne dans des environnements plus sensibles.
Alors, quel chemin d'intégration devriez-vous choisir?
Si vous avez des connaissances en matière de paie, de solides ressources en produits et en design, et une bonne raison de maîtriser l'expérience complète, l'API seule peut être judicieuse. Si vous avez besoin de rapidité maintenant et de contrôle plus tard, commencez par le composant et passez à une solution hybride au fil du temps.
Si vous voulez la voie pratique, commencez par le composant et passez à l'hybride au fil du temps. C'est ce que je recommanderais pour la plupart des plateformes. Lancez quelque chose de concret. Intégrez les données correctement. Observez ce que font les clients. Puis décidez ce qui vaut la peine d'être maîtrisé.
L'erreur est de considérer l'API seule comme l'option sérieuse et le composant comme le raccourci.
Parfois, l'API seule est l'option sérieuse. Parfois, c'est juste l'option la plus lente.
Le composant vous permet d'arriver sur le marché. L'API vous permet d'aller plus loin. La bonne réponse dépend de ce que vous essayez réellement de faire : lancer la paie, apprendre la paie ou intégrer la paie comme un élément central de votre produit.
Trouvez le chemin d'intégration de la paie qui convient à votre plateforme
Vous n'avez pas à choisir entre la rapidité et le contrôle sans comprendre les compromis. Si vous souhaitez définir le bon chemin API, Composant ou hybride pour votre plateforme, Nmbr peut vous aider.
