Tous les articles

Object-Oriented UX (OOUX) : qu’est-ce que c’est et à quoi ça sert dans une PME ?

Illustration de l’article sur l’Object-Oriented UX

Demandez dans une PME quelles notions existent exactement dans l’entreprise, et vous obtiendrez rarement une seule réponse. Les commerciaux parlent de dossier. La production dit commande. La comptabilité l’appelle une mission. Tous les trois parlent de la même chose, mais personne ne l’a jamais dit.

Tant que ça reste en réunion, c’est surtout agaçant. Dès qu’un logiciel entre en jeu, ça coûte cher. Car la question de savoir ce qu’est exactement une commande, et tout ce qui va avec, doit alors recevoir une réponse. Et c’est généralement le fournisseur qui la donne, pas vous.

Les gens pensent en choses, pas en étapes

Il existe une méthode de conception qui part justement de là : l’object-oriented UX, ou OOUX. L’approche vient de la designer américaine Sophia Prater, et l’idée est simple. Ne commencez pas par les écrans, mais par les notions que connaissent vos utilisateurs.

C’est bien comme ça que fonctionne la tête de vos collaborateurs. Un planificateur ne pense pas en « étape 3 de l’assistant de saisie ». Il pense en chantier, en technicien, en intervention. Ces choses, on les appelle des objets. Un objet, c’est quelque chose que l’on peut nommer, retrouver, et qui existe en plusieurs exemplaires. Il a des attributs (une adresse, une date, un statut), des relations avec d’autres objets, et des actions que l’on peut effectuer dessus.

Une entreprise d’installation de chauffage gère par exemple des Clients, des Chantiers, des Appareils, des Contrats d’entretien, des Interventions et des Factures. Six mots. Alignez-les, tracez les liens entre ce qui va ensemble, et en une demi-heure vous avez plus de structure sur la table qu’avec un classeur rempli de procédures.

Trois choses que ça vous apporte

Vous avez soudain un seul dictionnaire. Ça paraît banal, mais c’est de loin le plus grand gain. Tant que dossier, commande et mission coexistent, chaque discussion sur le logiciel porte à moitié sur la chose elle-même et à moitié sur ce que vous voulez dire. Un seul terme partagé par objet y met fin. En interne, et face à votre fournisseur.

C’est le meilleur contexte que vous puissiez donner. Si vous achetez un logiciel ou le faites développer, un modèle d’objets est bien plus utile qu’une liste de souhaits. Une liste de souhaits dit ce que vous voulez pouvoir faire. Vos objets disent ce que votre entreprise gère réellement. La première change selon le progiciel et le fournisseur. Les seconds restent valables, même si vous choisissez autre chose dans cinq ans.

Le travail en double apparaît. Écrivez pour chaque objet les actions qui existent et qui peut les effectuer, et les endroits bizarres sautent aux yeux. La même adresse saisie à trois endroits. Un statut que quelqu’un recopie chaque matin à la main d’un système à l’autre. Une validation qui revient officiellement au gérant, mais que plus personne ne donne en pratique.

Là où la méthode devient trop lourde

Soyons honnêtes : la méthode OOUX complète n’est pas faite pour une PME. Elle comporte quatre couches (objets, relations, actions et attributs) avec des matrices et plusieurs itérations, et cela devient vite un chantier de plusieurs semaines. Il n’y a ni le budget ni la patience pour ça. Le jargon n’aide pas non plus : personne autour de la table de la cuisine ne s’enthousiasme pour une « nested object matrix ».

Ce qui reste est en revanche utile, et c’est l’essentiel : les objets, les relations, et qui peut faire quoi. Les attributs de chaque objet, vous ne les détaillez qu’au moment où vous construisez réellement quelque chose. Une séance d’une demi-journée avec le gérant et deux collaborateurs clés, un résultat sur une seule feuille A3. Pas un rapport de quarante pages.

D’une feuille A3 à quelque chose qui dure

Cette feuille A3 a pourtant un point faible : c’est un instantané. Dans six mois, elle sera dans un classeur et ne sera plus juste.

C’est pourquoi, chez Tandem, nous travaillons avec un modèle de contexte : une seule description durable de la façon dont fonctionne votre entreprise. Les parcours montrent comment un processus se déroule du début à la fin. Les événements enregistrent ce qui se passe en chemin. Les écrans disent où les gens le voient et le modifient. Les objets en forment la couche de structure : les choses dont parlent ces parcours et ces événements.

Cette couche n’est pas un luxe. Les outils de développement IA peuvent aujourd’hui construire étonnamment beaucoup tout seuls, mais ils ont besoin des objets et de leurs relations pour livrer quelque chose de cohérent. Si vous ne les leur donnez pas, chaque prompt réinvente la façon dont votre entreprise est organisée, et chaque fois un peu différemment.

Ce que vous pouvez en faire

Prenez le processus qui pose le plus de problèmes aujourd’hui et soulignez chaque nom commun dans sa description. Regroupez les synonymes. Choisissez un seul mot par chose, et convenez que tout le monde utilise ce mot.

C’est généralement la première discussion où l’on découvre que trois personnes parlaient de trois choses différentes. Rien que pour ça, ça vaut la peine.

Curieux de savoir ce que ça donnerait pour votre entreprise ? Envoyez-nous un message.

Publié le 17 septembre 2026

Plus d’articles du studio

Tous les articles
Illustration de l’article « Comment le model-driven development améliore l’UX de votre logiciel »

Comment le model-driven development améliore l’UX de votre logiciel

Illustration de l’article « Le journey mapping pour les agents IA »

Le journey mapping pour les agents IA

Illustration de l’article : pourquoi l’UX n’a jamais été aussi importante

Pourquoi l’UX n’a jamais été aussi importante dans la création de logiciels