Choisir un partenaire de développement en marque blanche : ce que les agences vérifient d’abord

Une agence décroche un mandat qu’elle ne peut pas livrer à l’interne : un portail client, une intégration, une fonctionnalité de produit, une demande d’IA que personne au bureau ne sait mener plus loin qu’une démo. La réponse, c’est un partenaire technique qui travaille sous votre marque. Le risque, c’est que ce partenaire devienne le maillon faible du projet, sous échéance, devant votre client. Voici ce que les agences qui ont fait l’exercice plusieurs fois vérifient d’abord, et dans quel ordre.

Commencez par un petit mandat payé

Le portfolio, c’est la façon dont un partenaire se vend. Ce n’est pas la façon dont une agence le teste. Une étude de cas montre du travail fini, choisi par le partenaire, dont les semaines difficiles ont été retirées. Ce que vous devez savoir, c’est comment la personne se comporte avec une portée, une échéance et les changements de votre client, et la seule façon de l’apprendre est un petit mandat payé.

Choisissez quelque chose de réel mais de contenu : une page d’atterrissage, une fonctionnalité, une seule intégration. Prix fixe, date convenue. Jugez trois choses pendant que ça roule : si la portée a été questionnée intelligemment avant le début, si vous avez eu des nouvelles avant d’avoir à en demander, et si la livraison est arrivée à la date. Un mauvais résultat vous coûte une semaine. Un bon vous donne un partenaire pour des années.

Quatre conditions avant tout mandat client

Réglez-les par écrit avant le premier mandat, et gardez-les sur tous les suivants.

1. Un prix fixe tiré d’une portée écrite. Un compteur à l’heure déplace le risque d’erreur sur votre marge. Un prix fixe tiré d’une portée signée des deux côtés le renvoie au constructeur. Si un partenaire ne soumissionne qu’à l’heure, continuez de chercher.
2. Des délais convenus. Combien de temps entre une demande et un début, et ce qui arrive quand il est à pleine capacité. La bonne réponse à « peux-tu prendre ça la semaine prochaine » est parfois non, avec une date. Le partenaire qui dit oui à tout est celui qui échappe quelque chose.
3. Une non-sollicitation. Votre client reste le vôtre, par écrit, avant que vous ayez à le demander. Un partenaire qui l’offre de lui-même comprend sur quoi repose la relation.
4. La propriété. Le dépôt de code, l’infrastructure et les comptes appartiennent à votre client dès le premier jour, sous votre nom. Rien de ce dont le projet dépend ne devrait vivre uniquement chez le partenaire.

Une entente de confidentialité accompagne généralement ces conditions. Elle compte moins que la non-sollicitation. La plupart des partenaires signeront la première; moins nombreux sont ceux qui offriront la seconde.

Comment le travail devrait se dérouler

Le quotidien, c’est là que les agences se brûlent, et c’est facile à préciser.

• Invisible par défaut. Fichiers, environnements de préproduction et dépôts portent votre nom et vos gabarits. Le client voit votre agence.
• À vos appels quand c’est utile. Quand une question technique demande une réponse directe, le partenaire se joint comme membre de votre équipe, puis disparaît de nouveau.
• Une démonstration fonctionnelle chaque semaine, dans vos canaux. Pas un rapport d’avancement. Le logiciel, qui tourne, dans le Slack ou le Basecamp que vous utilisez déjà avec le client. Si vous ne le voyez pas fonctionner, il ne fonctionne pas.
• Le même fuseau horaire, et une personne. Les passations de nuit transforment une question d’une heure en délai de deux jours. Un partenaire que vous pouvez rencontrer en personne, dans la ville du client, élimine toute une catégorie de problèmes.

Choisissez la bonne pile technique

La bonne technologie est celle que votre équipe, ou celle de votre client, peut maintenir après le lancement. Un site de marque que le client modifiera lui-même appartient à un outil comme Webflow. Un produit avec des comptes, des données et des processus appartient au code, sur des technologies répandues qu’un prochain développeur reconnaîtra. Demandez au partenaire dans quoi il construit et dans quoi il refuse de construire. « N’importe quoi » est la mauvaise réponse : ça veut dire apprendre aux dépens de votre échéancier.

Exigez les deux langues

Un mandat torontois qui doit fonctionner au Québec, ou un mandat québécois qui vise le Canada anglais, échoue plus souvent sur le français que sur le code. Une interface traduite, des messages d’erreur en anglais, des courriels transactionnels dans la mauvaise langue. Si le projet touche les deux marchés, demandez si le partenaire écrit les deux langues nativement et s’il les intègre dès le premier commit. Ajouter le français après coup, c’est une reconstruction, et ça se voit sur votre marge. On a écrit pourquoi dans Un site en français n’est pas un site traduit.

La liste

Avant le premier mandat client, vous devriez pouvoir répondre oui à tout ceci.

• Nous avons fait un petit mandat payé ensemble, et il a été livré à la date.
• Le prix est fixe, tiré d’une portée signée des deux côtés.
• Les délais sont convenus, et nous savons ce qui arrive à pleine capacité.
• Une non-sollicitation est écrite.
• Notre client est propriétaire du code et des comptes.
• Nous voyons du logiciel qui fonctionne chaque semaine, dans nos canaux.
• La pile technique est une que notre client peut assumer après le lancement.
• Les deux langues sont couvertes si le mandat l’exige.

C’est l’arrangement sous lequel nous travaillons avec des agences de Toronto et du Québec. Si vous avez un mandat que personne ne peut prendre chez vous, décrivez-le en deux phrases et vous aurez une soumission ferme, une date, ou un non motivé en un jour ouvrable.