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

Reponse courte : un PDO Salesforce (Product Development Outsourcer) est un partenaire de conseil qui construit des applications commerciales sur la plateforme Salesforce pour des editeurs 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 a livrer sur Salesforce, pas quand il manque un developpeur. Cette distinction change le cadrage, le prix et l'evaluation de la mission.

Qu'est-ce qu'un PDO Salesforce ?

Un Product Development Outsourcer est un partenaire Salesforce specialise dans la construction de produits sur la plateforme, et non dans le parametrage de la plateforme pour une seule entreprise. Les ISV (editeurs de logiciels independants) lui confient les parties de la livraison qui sont propres a Salesforce : architecture du package, strategie de namespace et de dependances, licences, fiche AppExchange et la security review qui conditionne l'ensemble.

La difference en une ligne :

• Un integrateur adapte Salesforce a votre entreprise.
• Un PDO transforme votre idee en quelque chose que d'autres entreprises installent chez elles.

Que fait concretement 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 abonne.
• Packaging. 1GP ou 2GP, enregistrement du namespace, dependances entre packages et une strategie de versions tenable sur plusieurs annees.
• Security review. Preparation, 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-meme.
• Ingenierie de release apres le lancement. Correctifs, montees de version et versions poussees qui ne cassent pas des orgs que vous ne voyez pas.
• Modele de support. Un ISV supporte des installations qu'il ne controle pas : ce n'est pas le meme metier que supporter une seule org.

Seul le premier point ressemble a de la livraison Salesforce classique. Le reste releve des operations produit, et c'est la que les ISV debutants perdent des trimestres.

Quand faut-il recruter un PDO Salesforce ?

Cinq signaux, par ordre d'urgence approximatif :

1. Vous avez une these produit et un premier client pilote, mais aucun namespace ni decision de packaging ecrite. C'est le moment le moins couteux pour faire entrer un PDO, parce que rien n'est encore fige.
2. Votre application marche en sandbox et casse en package. Prefixes de namespace, SOQL dynamique et dependances entre packages echouent d'une facon que le code non package ne connait pas.
3. Vous abordez la security review pour la premiere fois. Le vrai risque n'est pas un refus isole, ce sont trois refus et deux trimestres perdus.
4. Vous etes en 1GP et vous voulez passer en 2GP. Salesforce a rendu Package Migrations generalement disponible en Summer '25 : la fonction convertit un package 1GP en 2GP et migre les abonnes deja installes. La question n'est plus si, mais quand et dans quel ordre.
5. Vous avez des abonnes et chaque release devient un risque. Des que d'autres entreprises dependent de vos numeros de version, l'ingenierie de release cesse d'etre optionnelle.

Pourquoi recruter un PDO est-il une decision produit et non une decision de staffing ?

La regie repond a une question de capacite : il nous faut deux developpeurs Apex de plus pendant six mois. Une mission PDO repond a une question produit : la version 1.0 doit etre publiee, revue et installable au deuxieme trimestre. Le second cadrage s'achete moins facilement et se pilote bien mieux, car presque toutes les erreurs couteuses en livraison ISV sont des decisions, pas des manques de bras.

Un namespace s'enregistre une fois et reste attache au package. Le choix 1GP ou 2GP fixe votre modele de release pour des annees. Ce que vous mettez dans le package determine ce que vous pourrez changer ensuite sans demander l'accord de chaque abonne. Rien de tout cela ne se resout en ajoutant de la capacite a une equipe qui n'a jamais livre de package.

Si votre travail Salesforce a une roadmap, des abonnes et un numero de version, vous achetez de l'ingenierie produit. Achetez-la comme telle.

Que controle reellement la security review AppExchange ?

La security review est une porte produit, pas un controle de style de code. Elle examine la maniere dont votre package traite les donnees, les secrets, le partage et les acces, et elle revient des 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 duree de vie de 30 jours pour un refresh token inactif et une liste d'IP autorisees, puis de s'auto-attester conformes sur ces quatre controles, avant le 11 mai 2026. Une fois l'attestation faite, les controles se verrouillent et ne peuvent plus etre desactives ; le non-respect peut entrainer un retrait de la fiche ou une suspension de l'interoperation. C'est exactement le type d'echeance qu'un PDO suit pour vous.

Comment choisir un PDO Salesforce ?

Posez quatre questions et donnez beaucoup de poids aux reponses :

• Quels packages avez-vous fait passer en security review, et dans quels secteurs ? Les secteurs regules relevent la barre.
• Montrez-moi un package 2GP que vous maintenez aujourd'hui. En construire un n'est pas la meme chose que le versionner chez des abonnes.
• Qui corrige si la review remonte des constats ? La reponse doit etre : eux.
• Que se passe-t-il apres le lancement ? Un partenaire qui disparait a la publication vous laisse la partie la plus dure.

Tekunda repond a ces questions par la livraison, pas par une plaquette. Nous sommes partenaire Salesforce certifie SI, ISV et PDO, nous avons passe la security review AppExchange dans la sante, la logistique et l'industrie, et nous maintenons des packages en production : Syntilio CareHub sert 12 organisations de soins ou plus sur l'AppExchange, et notre managed package 2GP pour ASSA ABLOY porte sa charge d'appareils connectes. Etre ISV et PDO fait aussi de nous un integrateur plus rapide, parce que des composants de qualite produit sont reutilises au lieu d'etre reconstruits. Voir comment nous travaillons.

FAQ

Que signifie PDO chez Salesforce ?

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

Quelle difference entre un PDO et un partenaire d'implementation Salesforce ?

Un partenaire d'implementation parametre Salesforce pour l'usage propre d'une entreprise. Un PDO construit un produit package 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 previsibles quand on l'a fait plusieurs fois.

Une nouvelle application AppExchange doit-elle demarrer en 1GP ou en 2GP ?

2GP est la voie moderne pour les nouveaux packages. Les editeurs deja en 1GP ne sont pas bloques non plus : Package Migrations, disponible depuis Summer '25, convertit un package 1GP en 2GP et migre les abonnes installes.

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

Avant que les decisions de namespace et de packaging ne soient prises. Ce sont les choix couteux a defaire, et ils tombent en general des la premiere semaine.