Ce que fait un PDO Salesforce, et quand en recruter un

Réponse courte : un PDO Salesforce (Product Development Outsourcer) est un partenaire de conseil qui construit des applications commerciales sur la plateforme Salesforce pour des éditeurs de logiciels, les package correctement et les fait passer par la security review de l'AppExchange. On en recrute un quand on a un produit à livrer sur Salesforce, pas quand il manque un développeur. Cette distinction change le cadrage, le prix et l'évaluation de la mission.

Qu'est-ce qu'un PDO Salesforce ?

Un Product Development Outsourcer est un partenaire Salesforce spécialisé dans la construction de produits sur la plateforme, et non dans le paramétrage de la plateforme pour une seule entreprise. Les ISV (éditeurs de logiciels indépendants) lui confient les parties de la livraison qui sont propres à Salesforce : architecture du package, stratégie de namespace et de dépendances, licences, fiche AppExchange et la security review qui conditionne l'ensemble.

La différence en une ligne :

• Un intégrateur adapte Salesforce à votre entreprise.
• Un PDO transforme votre idée en quelque chose que d'autres entreprises installent chez elles.

Que fait concrètement un PDO Salesforce ?

• Architecture produit. Ce qui entre dans le managed package, ce qui reste dans votre propre service, ce qui doit rester configurable par abonné.
• Packaging. 1GP ou 2GP, enregistrement du namespace, dépendances entre packages et une stratégie de versions tenable sur plusieurs années.
• Security review. Préparation, soumission et corrections quand les reviewers reviennent avec des constats.
• Licences et provisioning. La License Management App, les parcours d'essai et la fiche elle-même.
• Ingénierie de release après le lancement. Correctifs, montées de version et versions poussées qui ne cassent pas des orgs que vous ne voyez pas.
• Modèle de support. Un ISV supporte des installations qu'il ne contrôle pas : ce n'est pas le même métier que supporter une seule org.

Seul le premier point ressemble à de la livraison Salesforce classique. Le reste relève des opérations produit, et c'est là que les ISV débutants perdent des trimestres.

Quand faut-il recruter un PDO Salesforce ?

Cinq signaux, par ordre d'urgence approximatif :

1. Vous avez une thèse produit et un premier client pilote, mais aucun namespace ni décision de packaging écrite. C'est le moment le moins coûteux pour faire entrer un PDO, parce que rien n'est encore figé.
2. Votre application marche en sandbox et casse en package. Préfixes de namespace, SOQL dynamique et dépendances entre packages échouent d'une façon que le code non packagé ne connaît pas.
3. Vous abordez la security review pour la première fois. Le vrai risque n'est pas un refus isolé, ce sont trois refus et deux trimestres perdus.
4. Vous êtes en 1GP et vous voulez passer en 2GP. Salesforce a rendu Package Migrations généralement disponible en Summer '25 : la fonction convertit un package 1GP en 2GP et migre les abonnés déjà installés. La question n'est plus si, mais quand et dans quel ordre.
5. Vous avez des abonnés et chaque release devient un risque. Dès que d'autres entreprises dépendent de vos numéros de version, l'ingénierie de release cesse d'être optionnelle.

Pourquoi recruter un PDO est-il une décision produit et non une décision de staffing ?

La régie répond à une question de capacité : il nous faut deux développeurs Apex de plus pendant six mois. Une mission PDO répond à une question produit : la version 1.0 doit être publiée, revue et installable au deuxième trimestre. Le second cadrage s'achète moins facilement et se pilote bien mieux, car presque toutes les erreurs coûteuses en livraison ISV sont des décisions, pas des manqués de bras.

Un namespace s'enregistre une fois et reste attaché au package. Le choix 1GP ou 2GP fixe votre modèle de release pour des années. Ce que vous mettez dans le package détermine ce que vous pourrez changer ensuite sans demander l'accord de chaque abonné. Rien de tout cela ne se résout en ajoutant de la capacité à une équipe qui n'a jamais livré de package.

Si votre travail Salesforce a une roadmap, des abonnés et un numéro de version, vous achetez de l'ingénierie produit. Achetez-la comme telle.

Que contrôle réellement la security review AppExchange ?

La security review est une porte produit, pas un contrôle de style de code. Elle examine la manière dont votre package traite les données, les secrets, le partage et les accès, et elle revient dès que les exigences de la plateforme se durcissent.

L'exemple actuel que tout ISV devrait avoir dans sa roadmap, ce sont les connected apps. Le guide ISVforce de Salesforce impose aux partenaires d'activer OAuth PKCE, la rotation des refresh tokens, une durée de vie de 30 jours pour un refresh token inactif et une liste d'IP autorisées, puis de s'auto-attester conformes sur ces quatre contrôles, avant le 11 mai 2026. Une fois l'attestation faite, les contrôles se verrouillent et ne peuvent plus être désactivés ; le non-respect peut entraîner un retrait de la fiche ou une suspension de l'interopération. C'est exactement le type d'échéance qu'un PDO suit pour vous.

Comment choisir un PDO Salesforce ?

Posez quatre questions et donnez beaucoup de poids aux réponses :

• Quels packages avez-vous fait passer en security review, et dans quels secteurs ? Les secteurs régulés relèvent la barre.
• Montrez-moi un package 2GP que vous maintenez aujourd'hui. En construire un n'est pas la même chose que le versionner chez des abonnés.
• Qui corrige si la review remonte des constats ? La réponse doit être : eux.
• Que se passe-t-il après le lancement ? Un partenaire qui disparaît à la publication vous laisse la partie la plus dure.

Tekunda répond à ces questions par la livraison, pas par une plaquette. Nous sommes partenaire Salesforce certifié SI, ISV et PDO, nous avons passé la security review AppExchange dans la santé, la logistique et l'industrie, et nous avons livré et maintenu des packages en production : les managed packages Syntilio que nous avons conçus pour un ISV eHealth (2022 à 2025) sur l'AppExchange, et le managed package 2GP pour ASSA ABLOY qui porte sa charge d'appareils connectés. Être ISV et PDO fait aussi de nous un intégrateur plus rapide, parce que des composants de qualité produit sont réutilisés au lieu d'être reconstruits. Voir comment nous travaillons.

FAQ

Que signifie PDO chez Salesforce ?

Product Development Outsourcer : un partenaire de conseil Salesforce spécialisé dans la construction, le packaging et la publication d'applications commerciales sur l'AppExchange pour des éditeurs.

Quelle différence entre un PDO et un partenaire d'implémentation Salesforce ?

Un partenaire d'implémentation paramètre Salesforce pour l'usage propre d'une entreprise. Un PDO construit un produit packagé que de nombreuses entreprises installent, ce qui ajoute namespace, versionnage, licences et security review.

Faut-il un PDO pour passer la security review AppExchange ?

Non. Beaucoup d'ISV la passent seuls. Un PDO fait surtout gagner des cycles de review, car les constats habituels deviennent prévisibles quand on l'a fait plusieurs fois.

Une nouvelle application AppExchange doit-elle démarrer en 1GP ou en 2GP ?

2GP est la voie moderne pour les nouveaux packages. Les éditeurs déjà en 1GP ne sont pas bloqués non plus : Package Migrations, disponible depuis Summer '25, convertit un package 1GP en 2GP et migre les abonnés installés.

À quel moment un ISV doit-il faire entrer un PDO ?

Avant que les décisions de namespace et de packaging ne soient prises. Ce sont les choix coûteux à défaire, et ils tombent en général dès la première semaine.