Le product owner progiciel porte une plateforme achetée et paramétrée : ServiceNow pour les services informatiques et RH, Salesforce pour la relation client, SAP pour la finance ou la logistique. Plusieurs métiers partagent souvent la même instance. Il tient le backlog, anime les ateliers, écrit les stories et organise la recette, comme tout PO. La différence vient de l'éditeur, qui impose son modèle de données, son calendrier de versions et ses retraits de fonctionnalités.
Le profil recherché sait dire non à un développement spécifique en montrant ce qu'il coûtera à chaque release. Beaucoup de candidats viennent du conseil fonctionnel ou de l'AMOA et connaissent bien les écrans. Moins nombreux sont ceux qui ont mesuré la dette d'une instance, préparé une montée de version avec des tests de non-régression ou retiré des licences inutilisées. Sur un projet de fusion d'instances ou de reprise d'un existant chargé, cette expérience compte plus que le nombre de modules cités.
Le candidat raconte la dernière release de l'éditeur vécue en production. Le PDF contient 30 questions sur six axes, un cas de 20 minutes sur une instance ServiceNow partagée et une grille de 1 à 4.
Ce que le PO doit connaître de la plateforme
ServiceNow
Plateforme SaaS de gestion des services : ITSM (incidents, demandes, changements), CMDB, RH, service client. Elle publie deux familles de versions par an, nommées d'après des villes par ordre alphabétique (Zurich, Australia, Brazil). Le PO y suit la CMDB et son modèle CSDM, les applications de la ServiceNow Store et les personnalisations qui freinent les mises à jour.
Salesforce
CRM en SaaS, avec Sales Cloud pour les ventes et Service Cloud pour le service client, et une marketplace d'applications (AppExchange). Trois versions majeures par an, Spring, Summer et Winter, testables en avance sur un sandbox de prévisualisation. Les automatisations se construisent avec Flow, qui remplace les anciens outils de l'éditeur.
SAP S/4HANA
L'ERP de SAP, en cloud ou sur site. Les projets récents suivent la démarche SAP Activate, avec des ateliers de fit-to-standard, et l'approche clean core qui place les extensions à côté du cœur pour garder les mises à jour possibles. Le PO SAP travaille souvent sur un domaine fonctionnel (ventes, finance, achats).
Fit-to-standard et fit-gap
La démarche qui part du processus standard de l'éditeur, montré en démonstration, puis liste les écarts avec le besoin métier. Chaque écart est traité par paramétrage, par une adaptation du processus ou par une extension justifiée. C'est l'opposé d'un recueil de besoins sur feuille blanche.
Paramétrage, low-code et spécifique
Trois niveaux de modification, du moins coûteux au plus coûteux à maintenir : réglages standard, outils low-code de l'éditeur (Flow sur Salesforce, Flow Designer dans Workflow Studio sur ServiceNow), puis code. Plus on monte, plus chaque release demande de tests.
Dette de configuration
Les champs, scripts, règles et automatisations accumulés que plus personne ne maîtrise. Elle se voit aux régressions après une mise à jour, aux personnalisations ignorées par les montées de version et au temps de recette qui s'allonge.
Tests de non-régression
Les tests rejoués avant chaque version de l'éditeur et chaque livraison interne sur les processus critiques. ServiceNow propose son Automated Test Framework, d'autres plateformes passent par des outils du marché. Sans eux, la release de l'éditeur se teste en production.
Licences et modules
Le coût de la plateforme dépend des profils d'utilisateurs, des modules et des applications tierces. Le PO suit les comptes actifs, propose les retraits et participe aux décisions d'achat de nouveaux modules.
Le poste existe chez les clients finaux qui exploitent une instance sur la durée et dans les missions confiées à des ESN ou à des freelances. Les offres demandent presque toujours une plateforme précise, et parfois un module (CMDB sur ServiceNow, Service Cloud sur Salesforce, ventes ou finance sur SAP). Un PO expérimenté change de plateforme plus facilement qu'on ne le croit si la démarche est là, mais la connaissance du modèle de données et du rythme de l'éditeur se rattrape en quelques mois, pas en quelques jours. Les certifications de l'éditeur montrent la connaissance du produit, pas la tenue d'un backlog partagé par plusieurs métiers.
Six points attendus d'un PO progiciel
- Défense du standard face aux demandes métier
- Maîtrise de la dette de configuration
- Préparation des releases de l'éditeur
- Priorisation entre plusieurs métiers
- Gouvernance de la plateforme et des licences
- Adoption et qualité des données
Les questions d'entretien d'un product owner ServiceNow, Salesforce ou SAP
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un service métier veut garder son processus actuel, qui ne correspond pas au standard de l'outil. Comment menez-vous la discussion ?
Une bonne réponseLa personne montre d'abord le processus standard dans l'outil, sur un environnement de démonstration, et fait décrire l'écart en termes de résultat métier. Elle sépare ce qui relève d'une vraie contrainte (réglementaire, contractuelle) de l'habitude. Pour chaque écart, elle chiffre le coût d'un spécifique (développement, tests à chaque release, maintenance) et propose une adaptation du processus, un paramétrage, ou une extension documentée. La décision est écrite et validée par le sponsor.
Signal d'alerteDévelopper ce que le métier demande pour éviter le conflit, ou imposer le standard sans écouter. Une réponse qui ne parle jamais du coût futur d'un spécifique.
Question 2 · senior
Votre instance compte des centaines de règles, de scripts et de champs personnalisés ajoutés au fil des années. Comment traitez-vous cette dette de configuration ?
Une bonne réponseUn inventaire outillé (champs inutilisés, scripts sans propriétaire, automatisations en doublon), des mesures d'usage, puis un tri : ce qui est remplacé par le standard, ce qui est consolidé, ce qui est supprimé après vérification. Les travaux de nettoyage entrent dans le backlog avec un objectif mesurable, par exemple moins de régressions à la release ou un temps de test réduit. Une règle de gouvernance empêche la dette de revenir.
Signal d'alerte« On ne touche pas à ce qui marche. » Ou tout supprimer d'un coup sans mesurer l'usage ni prévenir les métiers.
Question 3 · confirmé
La version majeure de l'éditeur sera appliquée à votre production le mois prochain, à une date que vous ne choisissez pas. Comment la préparez-vous ?
Une bonne réponseLecture des notes de version avec un tri : ce qui change par défaut, ce qui est retiré, ce qui est intéressant pour les métiers. Mise à jour d'un environnement de préproduction ou d'un sandbox de prévisualisation, passage des tests de non-régression automatisés et manuels sur les processus critiques, revue des personnalisations touchées. Communication aux utilisateurs sur ce qui change pour eux, et plan de retour en cas de problème bloquant.
Signal d'alerte« L'éditeur teste ses releases. » Découvrir les changements en production, ou ne tester que les écrans les plus utilisés sans liste de processus critiques.
Question 4 · confirmé
Les ventes, le service client et la finance partagent la même instance et réclament tous la priorité. Comment construisez-vous le backlog ?
Une bonne réponseUn backlog unique avec des critères de priorisation partagés et publiés (valeur métier, risque, effort, dépendances avec la release éditeur), une capacité visible par sprint ou par release, et une instance de gouvernance où les métiers arbitrent ensemble. La personne rappelle qu'une modification pour un métier peut casser un autre processus sur l'objet commun, et le vérifie avant d'engager.
Signal d'alerteUn backlog par métier sans vue d'ensemble, ou la priorité donnée au métier qui finance le plus sans critère écrit.
Question 5 · senior
Un directeur métier veut acheter une application de la marketplace de l'éditeur pour son équipe. Que vérifiez-vous avant de dire oui ?
Une bonne réponseLe besoin réel et ce que le standard ou les modules déjà payés couvrent. Puis l'application : éditeur, support, compatibilité avec les releases, données qu'elle lit ou envoie hors de la plateforme (RGPD, sous-traitants), droits demandés, coût des licences par utilisateur et durée d'engagement. La personne passe la décision par la gouvernance de la plateforme et prévoit un propriétaire pour l'application.
Signal d'alerteInstaller en production parce que c'est « validé par l'éditeur », sans revue de sécurité ni propriétaire désigné.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
PO progiciel : les questions fréquentes
Un PO Salesforce peut-il passer sur ServiceNow ?
La démarche se transpose : standard d'abord, gouvernance, préparation des releases, priorisation entre métiers. Le modèle de données, les outils de déploiement et le vocabulaire changent, et les processus aussi, puisque ServiceNow sert surtout les services informatiques et Salesforce la relation client. Il faut quelques mois de montée en compétence. Pour une mission courte sur un existant complexe, une expérience sur la même plateforme reste préférable.
Quelle différence avec un consultant fonctionnel ou un business analyst ?
Le consultant et le business analyst analysent et spécifient, souvent sur un périmètre de projet. Le PO décide de l'ordre et du contenu des livraisons, dit non et répond de la valeur livrée sur la durée. Sur un progiciel, il tient aussi le calendrier imposé par l'éditeur et la santé de l'instance. Un bon consultant ne devient pas PO s'il n'a jamais arbitré entre plusieurs métiers.
Quel test technique est donné à un PO progiciel ?
Pas de code. Le candidat reçoit un extrait réel de notes de version de l'éditeur et une liste de personnalisations de l'instance, et dit ce qui risque de casser et ce qu'il faut tester. Ou bien il traite trois demandes métier en vingt minutes : standard, paramétrage ou refus. Cet exercice montre vite si la personne connaît la plateforme ou seulement ses écrans.
Les certifications de l'éditeur sont-elles un bon filtre ?
Elles montrent une connaissance du produit, à condition d'être à jour : Salesforce et ServiceNow demandent un maintien régulier de leurs certifications. Une certification d'administrateur ne dit rien de la tenue d'un backlog ni des arbitrages entre métiers. Elle sert d'indice sur la plateforme, et le reste se vérifie par des situations vécues : une release préparée, un spécifique refusé, une instance nettoyée.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
