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 Salesforce qui construit des applications commerciales sur la plateforme pour des éditeurs de logiciels, les package et les fait passer par la security review jusqu'à AgentExchange, la marketplace qui a absorbé AppExchange en avril 2026. On en recrute un quand on a un produit à livrer sur Salesforce, pas quand il manque un développeur.

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 sur la marketplace 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. Si ce n'est pas encore tranché, notre guide sur les modèles de packaging Salesforce pour ISV expose les compromis avant qu'un PDO ne les fige.
• 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. Ce périmètre complet, de la première conception au package publié, est celui de notre service de développement d'application AppExchange.

Qu'est-ce qui a changé en 2026 pour les PDO et les ISV Salesforce ?

Trois évolutions de la plateforme changent ce qu'un PDO doit maîtriser cette année :

• AppExchange est devenue AgentExchange. Le 17 avril 2026, Salesforce a annoncé AgentExchange, une marketplace unique qui réunit AppExchange, la Slack Marketplace et l'écosystème Agentforce, avec plus de 10 000 applications Salesforce et partenaires. Chaque solution publiée passe toujours par la security review.
• Les connected apps ont cédé la place aux external client apps. La documentation développeur de Salesforce indique que la création de connected apps est restreinte depuis Spring '26 et recommande les external client apps. Trailhead présente la possibilité de distribuer les external client apps avec des managed packages de seconde génération comme leur plus grand avantage, les identifiants OAuth consumer restant hors du package.
• L'échéance de durcissement OAuth est passée. Les partenaires avaient jusqu'au 11 mai 2026 pour activer quatre contrôles sur leurs applications et s'auto-attester. Détails plus bas.

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. Notre guide sur la façon dont les ISV réussissent la Security Review AppExchange montre où ces cycles se perdent le plus souvent.
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, et quels choix 2GP deviennent définitifs une fois faits. Les external client apps renforcent encore l'argument, car elles sont conçues pour être livrées en 2GP.
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 Salesforce ?

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, c'est OAuth sur les connected apps et les external client apps. Le guide ISVforce de Salesforce imposait 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 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 guide avertit que le non-respect peut entraîner un retrait de la fiche ou une suspension de l'interopération avec Salesforce. Si votre application a manqué cette date, c'est désormais un chantier de remédiation et non un point de roadmap, exactement le type d'obligation qu'un PDO suit pour vous.

Pour la review elle-même, notre checklist de security review Salesforce liste les constats courants à corriger dans l'ordre avant de soumettre, et notre service de security review prend en charge la soumission et les corrections.

Comment choisir un PDO Salesforce ?

Posez cinq 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.
• Comment gérez-vous les external client apps et les contrôles OAuth 2026 ? Un PDO à jour répond sans avoir à chercher.
• 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. Parlez-nous de votre application.

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 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 ?

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.

Un PDO Salesforce est-il la même chose que Plauti PDO ?

Non. Plauti Data Orchestration, aussi abrégé PDO, est un produit Salesforce de Plauti. Un PDO Salesforce est un type de partenaire de conseil.

À 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.