Définir le problème avant de construire la solution
Dans ce projet PIM, les API sont devenues simples seulement après l’alignement sur les problèmes métier et la validation d’un futur modèle avec les utilisateurs.
- Domaine
- Analyse métier
- Contexte
- Projet professionnel anonymisé
Vue d’ensemble
Le projet était présenté comme une implémentation PIM avec des échanges entre SAP, Akeneo et plusieurs systèmes en aval. Je pensais que la difficulté principale serait dans les mappings et les API.
En réalité, les questions les plus longues sont arrivées bien avant : que représentait exactement un SKU, quelles variantes avaient un sens métier distinct et quelles pratiques actuelles devaient réellement survivre dans le futur système ?
Une fois ces points stabilisés, la partie technique est devenue beaucoup plus directe.
Contexte
Plusieurs départements travaillaient sur le même catalogue, mais pas pour les mêmes usages. Marketing, Produit, IT et spécialistes de la donnée ne regroupaient pas toujours les produits de la même manière. Dans SAP, une définition de SKU pouvait couvrir plusieurs variantes métier, avec quelques cas particuliers difficiles à représenter proprement.
Recopier la structure existante dans le PIM aurait simplement déplacé l’ambiguïté. Le projet devait donc définir un modèle cible, pas seulement migrer l’ancien.
L’équipe de conseil était volontairement réduite : un chef de projet, un consultant PIM senior et deux analystes métier. Côté client, les ateliers réunissaient les personnes qui prenaient réellement les décisions ou qui allaient vivre avec leurs conséquences.
Définir le problème
Le client n’est pas arrivé avec une liste propre de problèmes validés. Les participants parlaient surtout d’irritants : mises à jour manuelles, attributs confus, création produit laborieuse, données peu fiables.
Après chaque atelier, nous reprenions ces observations en équipe. Nous cherchions à distinguer un vrai problème métier, une limite héritée des outils actuels et une habitude certes pénible mais qui ne justifiait pas de transformer le modèle.
Lors de l’atelier suivant, nous présentions notre compréhension pour la faire challenger. Cette boucle nous a évité de transformer chaque irritation en exigence.
Prendre les décisions
Les bons participants dépendaient de la question. Les définitions de données exigeaient les personnes connaissant l’historique du catalogue ; le futur workflow concernait Produit et Marketing ; la faisabilité impliquait l’IT et le consultant PIM.
Aucun groupe ne pouvait définir seul le modèle. Le client détenait la connaissance métier et historique ; notre équipe apportait l’analyse et l’expertise de la plateforme.
Valider les décisions
Nous n’avons pas validé le modèle uniquement avec des schémas ou des spécifications. Dès qu’une direction devenait assez claire, le consultant la configurait dans l’environnement de développement Akeneo.
Les futurs utilisateurs pouvaient alors créer des produits, modifier des attributs et suivre le workflow proposé. Ce retour était plus utile qu’une démonstration : un parcours peut sembler convaincant lorsqu’on le regarde, puis devenir pénible dès qu’on doit l’exécuter soi-même.
Certaines configurations confirmaient le modèle. D’autres révélaient des hypothèses que les ateliers n’avaient pas fait ressortir. Nous ajustions puis recommencions.
Résultat
Lorsque les travaux API ont commencé, les décisions métier les plus difficiles avaient déjà été prises. Les mappings s’appuyaient sur des concepts compris de la même manière et les règles de validation découlaient de définitions testées avec les utilisateurs.
Les API n’étaient pas triviales, mais elles n’avaient plus à compenser un modèle flou.
Perspective
Je voyais auparavant l’intégration surtout comme un contrat entre systèmes. Ce projet a rendu beaucoup plus visible sa dimension organisationnelle.
Deux systèmes peuvent échanger des données techniquement valides alors que les équipes ne leur donnent pas le même sens. Dans ce cas, un appel API réussi prouve très peu de choses.
Le travail le plus utile s’est déroulé avant l’implémentation : transformer les irritants en problèmes validés, construire un modèle commun et le tester tant qu’il restait peu coûteux à modifier.
À retenir
Les API sont devenues simples parce que l’organisation avait déjà fait le travail plus difficile : s’accorder sur le sens des données.