Conception centrée sur le développement

Introduction — La conception centrée sur le développement 

Dans la majorité des entreprises œuvrant dans le développement de logiciels, la programmation est perçue comme le cœur battant de l’activité. Les organigrammes lui réservent la plus grande place, les budgets l’alimentent avec constance, et les processus comme Agile tournent autour des sprints de code. Dans ce paradigme, la conception d’interfaces est souvent vue comme un “plus”, un ajout esthétique ou ergonomique, souvent relégué aux marges, parfois même à l’extérieur du processus de développement lui-même.

Mais que se passerait-il si cette perspective était inversée? Et si l’activité centrale d’une organisation logicielle n’était pas la programmation, mais la conception centrée sur l’humain? Et si, au lieu de coder d’abord et tester ensuite, nous faisions l’exercice rigoureux de comprendre les besoins réels, les contraintes cognitives, les environnements d’usage, avant même la première ligne de code?

Ce texte propose une réorientation stratégique de la structure même des projets logiciels. Une transformation des priorités, où l’humain, ses capacités, ses limites et ses contextes d’usage deviennent les véritables moteurs de décision. Car concevoir un logiciel, ce n’est pas simplement résoudre un problème technique — c’est créer une expérience. Et cette expérience, trop souvent, échoue non pas à cause d’un bug, mais d’un manque d’empathie, d’écoute, de validation.

L’article mettra en lumière :

1. Pourquoi la conception reste un pilier négligé dans le monde logiciel.

2. Quels sont les coûts, visibles et invisibles, du modèle centré sur le développement.

3. Ce qu’implique réellement une approche de conception centrée sur l’humain (ISO 9241-210).

4. Et enfin, les avantages stratégiques, humains et financiers qu’apporte ce changement de paradigme.

1. La conception comme pilier négligé du développement logiciel 

Il est rare, dans les organisations logicielles, que la conception d’interfaces soit reconnue comme une discipline à part entière. Trop souvent, elle est perçue comme un enrobage superficiel ou une simple “étape préliminaire”. Cette perception erronée est ancrée dans la culture même de ces entreprises, façonnée par des décennies où les enjeux techniques dominaient largement les préoccupations humaines.

Une des raisons profondes tient à la genèse même des projets informatiques : ils sont fréquemment dirigés par d’anciens programmeurs, des gestionnaires qui ont un fort bagage technique, mais peu ou pas de formation en ergonomie ou en conception centrée utilisateur. Pour ces décideurs, l'interface est trop souvent vue comme quelque chose qui “vient à la fin” ou, pire encore, comme quelque chose qui se règle “au feeling”. Le développement logiciel, dans leur esprit, commence dès qu’on se met à coder dans un environnement de développement. Or, cette vision est réductrice, voire contre-productive.

Il faut aussi admettre que les métiers de la conception d’interfaces sont jeunes. L’ergonomie cognitive, l’expérience utilisateur (UX), les tests d’utilisabilité ou les maquettes interactives sont encore perçus comme des “nouveautés” dans plusieurs organisations. Trop peu de gens savent que des normes internationales comme l’ISO 9241-210 existent, qu’elles précisent clairement ce qu’est une bonne démarche de conception centrée sur l’humain.

Un autre facteur explicatif est la faible maturité UX dans les milieux techniques. La hiérarchie des tâches, la navigation, l’accessibilité, les affordances ou l’odeur de l’information sont des notions souvent ignorées. Résultat : les applications naissent du code, pas d’un besoin humain clairement défini.

Enfin, il ne faut pas négliger la place qu’occupe l’obsession pour la performance technique. L’optimisation, la scalabilité, la sécurité, la dette technique : tous ces concepts, bien que fondamentaux, éclipsent trop souvent la question suivante : “Est-ce que l’utilisateur comprendra ce que nous avons conçu ?” La culture du design reste marginale, souvent cantonnée à l’esthétique ou à l’identité visuelle, loin des fondements ergonomiques.

Si la programmation bénéficie d’un culte légitime autour de la complexité maîtrisée, la conception mérite un respect équivalent pour sa capacité à traduire les besoins humains en solutions concrètes. Elle ne devrait pas être accessoire, mais structurelle, car ce sont les choix de conception qui tracent la carte que les programmeurs devront ensuite coder.

2. Les limites du modèle centré sur le développement 

Lorsque le développement logiciel est dominé par la programmation, et que la conception est marginalisée ou improvisée, les coûts réels — économiques, humains, stratégiques — se révèlent avec le temps. Le plus souvent, ils apparaissent trop tard, dans des phases où les marges de manœuvre sont réduites et où chaque correction devient un gouffre.

Il existe un graphique bien connu dans le milieu de l’ingénierie logicielle, produit par le IBM System Science Institute, qui illustre de façon frappante le coût exponentiel des corrections de défauts selon la phase de développement. Corriger un problème dans la phase de maintenance coûte jusqu’à 100 fois plus cher que de l’avoir anticipé en phase de conception. Pourtant, malgré cette évidence, la majorité des projets attendent que le logiciel soit livré ou utilisé pour commencer à observer les vrais problèmes.

Les entreprises centrées sur le développement ont souvent des processus bien rodés pour livrer rapidement du code fonctionnel. Mais cette efficacité apparente masque une réalité : les utilisateurs ne trouvent pas leur compte. Trop d’applications sont abandonnées, peu utilisées ou contournées. Les équipes techniques accusent alors les utilisateurs de “ne pas comprendre” ou de “ne pas s’adapter”, alors que le véritable échec est celui de la conception.

Les échecs d’implantation sont nombreux. Les employés retournent aux anciens outils, développent leurs propres “workarounds”, ou perdent un temps précieux à chercher comment accomplir leurs tâches. La satisfaction diminue, les formations se multiplient, le soutien technique est débordé. Et, pendant ce temps, les gestionnaires s’étonnent que le produit “ne fonctionne pas”, malgré tous les efforts investis dans son développement.

Il y a aussi un coût en capital humain. Les équipes de développement, souvent confrontées à des refontes de dernière minute, vivent de la frustration. Le travail est jeté, repris, corrigé dans l’urgence. Le moral baisse, la motivation aussi. Ce cercle vicieux affecte la rétention des talents, en particulier ceux qui ont une sensibilité pour la qualité de l’expérience utilisateur.

À cela s’ajoute un coût stratégique : les projets centrés sur la programmation échouent souvent à se démarquer sur le marché. Les interfaces peu intuitives, les expériences frustrantes, la complexité inutile — tout cela nuit à la compétitivité. À long terme, ne pas investir dans la conception revient à miner sa propre capacité d’innovation.

Un modèle centré sur le développement n’est pas nécessairement voué à l’échec. Mais ses limites structurelles doivent être reconnues. Car un logiciel, aussi robuste soit-il, ne remplit pas sa mission s’il n’est pas adopté, compris et apprécié par ses utilisateurs.

3. La conception centrée sur l'humain 

Face aux limites du modèle de développement centré sur la programmation, la conception centrée sur l’humain (ou HCD pour Human-Centered Design) apparaît non seulement comme une solution pertinente, mais comme une nécessité organisationnelle. Cette approche, codifiée notamment dans la norme ISO 9241-210, repose sur un principe fondamental : un produit ne peut réussir que s’il est conçu à partir des besoins, des capacités, des limites et du contexte réel de ses utilisateurs.

Contrairement à une conception intuitive ou décorative, le HCD est un processus structuré, itératif et collaboratif, qui commence bien avant la première ligne de code. Il inclut des activités comme :

• la définition de personas et de scénarios d’usage,

• l’observation sur le terrain des tâches réelles effectuées,

• la co-création avec les utilisateurs,

• la modélisation des interfaces à l’aide de maquettes interactives,

• des tests d’utilisabilité permettant de détecter et corriger des problèmes avant le développement.

L’idée n’est pas de remplacer les développeurs, mais de leur offrir une vision claire, validée, testée de ce qu’ils doivent coder. En cela, la conception centrée sur l’humain est un réducteur de risques : les choix ont été testés, les éléments validés, les parcours optimisés. On ne demande plus au développeur de deviner l’intention du produit : on lui confie la mission de concrétiser une interface déjà alignée avec les utilisateurs finaux.

Un exemple marquant de cette efficacité est celui des tests d’utilisabilité menés sur des maquettes interactives. Dans une étude menée sur un logiciel de gestion de la santé et sécurité, les tests ont permis de révéler plus d'une centaine de problèmes d’utilisabilité à coût très faible. Si ces problèmes avaient été découverts en production, leur correction aurait été fastidieuse, coûteuse, voire impossible.

Mais adopter cette démarche, c’est aussi affronter des résistances. Il faut souvent convaincre des gestionnaires sceptiques, former les équipes, redéfinir les priorités de projet. Certaines entreprises considèrent encore la conception comme “du flou artistique” ou une “perte de temps”. Pourtant, les organisations qui ont intégré cette philosophie de manière systématique — que ce soit dans le domaine bancaire, la santé ou les services numériques — en retirent des bénéfices mesurables : amélioration de la satisfaction client, réduction des coûts de support, accroissement de la productivité, hausse des ventes.

La conception centrée sur l’humain n’est pas une lubie de designers. C’est une méthodologie rigoureuse, ancrée dans la recherche scientifique, la psychologie cognitive et l’analyse systémique. Elle exige des compétences précises, des outils adaptés, mais surtout une volonté organisationnelle de recentrer le développement… sur l’humain.

4. Les avantages stratégiques, humains et financiers d’un changement de paradigme 

Changer de paradigme pour placer la conception centrée sur l’humain au cœur du développement logiciel n’est pas une simple amélioration de processus — c’est une transformation organisationnelle qui modifie en profondeur la manière dont une entreprise crée de la valeur.

Sur le plan stratégique, cette approche constitue un avantage concurrentiel clair. Les produits conçus avec les utilisateurs, pour les utilisateurs, ont plus de chances d’être adoptés, appréciés et recommandés. Ils répondent aux besoins réels plutôt qu’aux projections internes. En intégrant l’expérience utilisateur dans les premières étapes, les entreprises réduisent drastiquement les risques de rejets ou d’échecs à l’implantation. Le temps de mise sur le marché est aussi optimisé, car moins de révisions sont nécessaires en aval.

Du point de vue financier, les bénéfices sont tangibles. La règle du facteur 100x évoquée plus tôt illustre à quel point il est rentable de corriger les problèmes de conception avant le développement plutôt qu’après. Moins de coûts en support technique, moins de formations nécessaires, moins de clients perdus par frustration. L’investissement initial dans la conception est souvent récupéré dès les premiers mois d’utilisation du produit.

Sur le plan humain, l’impact est tout aussi puissant. Les utilisateurs finaux se sentent considérés, impliqués, écoutés. Cela améliore leur engagement, leur satisfaction, et leur fidélité à l’outil ou au service. Du côté des équipes internes, une conception validée facilite le travail des développeurs, réduit les allers-retours, limite la pression et les tensions. L’ambiance s’en trouve améliorée, la rétention de talents augmentée.

D’un point de vue culturel, intégrer la conception centrée sur l’humain transforme aussi la façon dont une organisation perçoit l’innovation. Plutôt que de miser sur la complexité technique comme marque de prestige, elle valorise l’intelligence de conception, la simplicité fonctionnelle, la clarté, la fluidité. Elle cultive une culture de l’écoute et de l’empathie — valeurs trop souvent absentes dans les structures purement techniques.

Et, enfin, du point de vue organisationnel, cette approche pousse à la transversalité : elle invite les développeurs, les concepteurs, les gestionnaires, les testeurs et les utilisateurs à collaborer dès le départ, dans une logique d’intelligence collective. Cela brise les silos, encourage la diversité des points de vue, et renforce la qualité globale du produit.

Changer de paradigme demande du courage. Mais les entreprises qui s’engagent réellement dans cette voie récoltent des bénéfices qui dépassent largement leurs attentes. Il ne s’agit plus seulement de livrer un logiciel. Il s’agit de concevoir une solution utile, utilisable et utilisée — la véritable définition du succès.

Conclusion — Réorienter le logiciel vers l’humain 

Repenser la structure d’un projet logiciel en y plaçant la conception centrée sur l’humain au cœur du processus, ce n’est pas simplement une question de méthode. C’est une question de vision. Tout au long de cet article, j’ai tenté de démontrer que l’approche actuelle, centrée sur la programmation, bien qu’efficace à certains égards, comporte des limites profondes — des coûts évitables, des échecs d’implantation, une insatisfaction chronique des utilisateurs.

En m’appuyant sur la norme ISO 9241-210, sur mon expérience en ergonomie cognitive, et sur de nombreux exemples issus du terrain, j’ai proposé une réorientation du développement logiciel. Une approche où la conception est stratégique, planifiée, validée, itérative, et surtout, centrée sur les humains qui utiliseront l’interface, pas uniquement sur les machines qui l’exécuteront.

Nous avons exploré :

• les biais organisationnels qui marginalisent la conception,

• les pertes financières et humaines liées à ce modèle dominant,

• les avantages concrets d’une conception menée avec rigueur, empathie et méthode,

• et l’impact positif qu’un tel changement peut avoir sur les équipes, les utilisateurs et la performance de l’entreprise.

Il ne s’agit pas de diminuer l’importance du développement logiciel, mais de reconnaître que ce qui est développé doit d’abord être bien conçu. Le code, aussi élégant soit-il, ne vaut rien s’il ne répond pas à un besoin réel, dans un contexte réel, pour des personnes réelles.

Nous avons les outils, les méthodes, les normes. Ce qui manque encore souvent, c’est le courage de faire les choses autrement.