Sur l’écran d’approbation d’un devis, l’action s’appelle « Validation ». Dans la liste à côté, la même étape s’appelle « Accord ». Et dans l’e-mail que reçoit votre client, on lit « Confirmé ». Personne n’en a décidé ainsi. C’est venu comme ça.
Si vous faites développer des logiciels, vous connaissez. De petites incohérences, chacune inoffensive, mais qui ensemble font que votre équipe hésite, se trompe et finit par retourner à Excel. Et maintenant que l’IA écrit de plus en plus de code, les logiciels grossissent plus vite que jamais. Ces incohérences aussi.
Le model-driven development est une façon d’en garder la maîtrise. L’idée : vous décrivez d’abord dans un seul modèle comment fonctionne votre entreprise, avec ses processus, ses notions et ses règles. Le logiciel est construit à partir de ce modèle, et vérifié par rapport à lui. On le présente généralement comme quelque chose de technique, réservé aux développeurs. Mais vos utilisateurs voient aussi la différence.
Le logiciel suit leur façon de travailler, pas votre base de données
Beaucoup de logiciels de gestion sont construits autour de tables : clients, commandes, produits. Chacune a sa liste et son formulaire. Pratique pour qui le construit, moins pour qui s’en sert. Vos collaborateurs ne pensent pas en tables, mais en tâches : établir un devis, planifier une livraison, traiter une réclamation.
Si le modèle décrit ces tâches et ces processus, le logiciel suit la même logique. Chaque écran existe parce que quelqu’un doit y faire quelque chose, et montre exactement ce qu’il faut pour cela. Tout commence par bien cartographier la façon dont les gens travaillent vraiment.
Un seul modèle, c’est aussi un seul vocabulaire. Un client s’appelle client partout, un statut veut dire la même chose partout, et la même règle s’applique sur chaque écran. C’est le même principe que l’object-oriented UX : d’abord bien définir les notions, ensuite les écrans.
Éviter les erreurs plutôt que les signaler
Tout le monde connaît le message d’erreur après avoir rempli un long formulaire : « Une erreur s’est produite. » Ces messages existent parce que les règles sont enfouies quelque part dans le code, et que l’interface ne les découvre que quand il est trop tard.
Si les règles figurent explicitement dans le modèle, le logiciel sait à l’avance ce qui est permis. Le bouton d’une action qui n’est pas encore possible est désactivé, et dit pourquoi : « Ce devis n’a pas encore de contact. » Le comportement du logiciel devient plus prévisible : il fait ce que dit le modèle.
Un logiciel qui ne se dégrade pas en silence
C’est peut-être le plus grand avantage, et le moins visible. La qualité d’un logiciel se dégrade rarement d’un coup. Ça se fait petit à petit : une mise à jour ici, une modification rapide là. Au bout d’un an, le bouton que vous utilisez tous les jours a changé de place, ou il a disparu.
Avec l’IA, ça peut aller plus vite. Un outil d’IA travaille avec le contexte qu’il reçoit à ce moment-là, et ce qui n’y figure pas peut sauter à la modification suivante. C’est pourquoi lui donner le bon contexte est si important. Si chaque modification passe par le modèle et que le code est vérifié par rapport à lui, une étape disparue ou une règle modifiée se remarque tout de suite. Pas quand un client appelle.
Ce que le designer voulait se retrouve dans le logiciel
Dans beaucoup de projets, les maquettes vivent dans un fichier à part : un Figma, un document, une série de captures d’écran. Le logiciel est construit à côté et s’en éloigne lentement. Après trois versions, plus personne ne regarde la maquette.
Un bon modèle est lisible par des gens qui n’écrivent pas de code. Ce que vous apprend une discussion avec vos utilisateurs devient ainsi une modification du modèle, qui arrive d’elle-même dans le logiciel. Et comme une modification donne vite une version qui fonctionne, vous pouvez tester plus souvent avec de vrais utilisateurs plutôt qu’avec des maquettes. C’est important, car construire vite la mauvaise chose, ça reste la mauvaise chose.
Un modèle, tous les canaux
Votre logiciel a de plus en plus souvent plus d’un type d’utilisateur. Une application web, une application mobile, une connexion avec un autre système, et de plus en plus souvent des agents IA qui exécutent des tâches pour vos collaborateurs. S’ils viennent tous du même modèle, ils se comportent de la même façon : mêmes règles, mêmes notions, même résultat.
Notre approche
Chez Tandem, le modèle est le point de départ de chaque projet. Nous cartographions d’abord comment les gens travaillent : quelles étapes ils suivent, quelles notions ils utilisent et quelles règles s’appliquent. C’est du travail d’UX, et il devient la fondation à partir de laquelle le logiciel est construit, même quand c’est l’IA qui construit. Ce qui est construit, nous le vérifions par rapport à ce modèle.
Vous voulez savoir si votre propre logiciel en profiterait ? Posez-vous une seule question : est-ce que quelque part, il est décrit comment fonctionne votre entreprise, indépendamment du code ? Si la réponse est non, ce savoir est dans la tête de quelques personnes. Ou nulle part.
Curieux de savoir ce qu’un modèle peut apporter à votre logiciel ? Envoyez-nous un message, nous serons heureux d’y réfléchir avec vous.
