Discussion :

[blobr]

Hello a tous !

Nous effectuons des recherches chez Blobr sur le sujet de l'onboarding et l'intégration d'APIs externes, nous sommes très intéressés de savoir ce que vous avez vécu et ce que vous en avez pensé.

Qu'est-ce que vous détestez le plus dans l'expérience d'onboarding et l'intégration d'APIs ?

Vous pouvez répondre dans les commentaires ou remplir ce rapide sondage https://docs.google.com/forms/d/e/1F...gjPtg/viewform — cela prend 2 minutes.

[Auteur]

Qu'est-ce que le onboarding ?

Car mes recherches sur ce terme me donnent cette définition

Le processus d'onboarding regroupe toutes les pratiques liées à l'accueil et à l'intégration d'un nouveau salarié.

et du coup quels sont les rapports avec les API ?

[blobr]

C'est un peu la meme analogie, c'est toutes les "pratiques" liées à l'accueil d'un developpeur sur une API pour qu'il ait la meilleure experience
lors de la decouverte et l'integration de l'API : cela a pour but d'augmenter l'adoption de l'API par les devs.

Par exemple, le dev va avoir acces a un portail developpeur : des fois ca sera juste une interface super basique de type Swagger UI, des fois
ca sera un site beaucoup plus avance comme le portail de Stripe, Slack etc

Cela peut se manifester sous plusieurs formes : une belle interface, une doc complete et a jour, des outils pour faciliter la vie aux devs (code snippet, playground, etc)

[escartefigue]

C'est donc clair : il s'agit de staffer un executive developper dans la team, de le coacher aux best practices pour qu'il puisse performer... ASAP bien sûr.

Bien entendu, le sondage est également en anglais (à part la réponse "autre" ) sinon ça aurait fait tâche.

Heureusement que nous sommes sur un site francophone

[blobr]

C'est plus a destination des dev que des executives, si je donne un exemple d’un scenario.
Vous êtes dev et vous devez utiliser ou intégrer une API de paiement (CB, SEPA, etc) pour vos besoins personnels ou pour votre entreprise dans le but de créer une application derrière : un site commercial de type market place.

Vous allez souscrire à une API : on va prendre 1 API fictive monpaiement.com
Imaginons que sur monpaiement.com que la documentation soit mal faite : moyen de s'authentifier pas clair ou mot de passe introuvable, documentation pas à jour / champs obsolètes ou non expliques, aucune explication des termes fonctionnels et de l'utilisation du workflow de l'API, aucun exemple, pas de code généré, support client inexistant. L’expérience du dev sera désastreuse : il va mettre un temps fou pour comprendre l’API a intégrer et effectivement il y aura une perte de temps et de productivité pour lui et/ou son entreprise.

[Auteur]

Si un logiciel ou des bibliothèques ne sont pas documentées, je jette. Je ne vais pas me casser la tête à essayer de comprendre et surtout intégrer dans un projet un truc non documenté.

Tout comme toi, escartefigue, je déteste le charabia franglais (un pléonasme).