Discussion passionnante, hier, avec Theodo.
On a pas mal échangé, en particulier sur les interfaces.
Bien sûr, côté Front Office, la question ne se pose pas : on se doit de proposer des interfaces faciles à utiliser, intuitives, rapides, …
Mais la question peut se poser côté back office.
Autant il est évident que certaines fonctions se font très bien via des interfaces, bien souvent web. Exemple : ajouter ou mettre à jour un produit dans le catalogue, ajouter une image, …
Mais pour certaines fonctions bien plus avancées, la question peut se poser.
Exemple : gestion des processus (workflow).
Est-ce vraiment une bonne idée que de développer un moteur graphique, pour représenter des choses aussi complexe que la modélisation des processus ?
Regardons les deux faces du sujet :
Si on a une interface :
L’interface donne un cadre, et elle permet de contrôler qu’on reste dans ce cadre.
Si on prend l’hypothèse que cette interface est bien faite, (hum hum), cela va permettre d’aider l’utilisateur à paramétrer le système.
Exemple intéressant de mon point de vue : le module de paramétrage des promos sur Magento.
Bon, l’exemple est certe particulier, parce qu’on voit bien que le résultat est finalement très très proche d’un programme…
Si on n’a pas d’interface :
Si on n’a pas d’interface, on va devoir utiliser un langage de description du sujet.
Ce langage peut être un langage hôte (PHP, Java, …) ou une syntaxe XML ou YAML, ou enfinun nouveau langage spécifique.
Si on prend un langage hôte, l’avantage est qu’on peut exprimer directement le problème sous forme d’un programme.
L’énorme avantage est qu’on n’aura pas à développer d’interface, complexe et très cher.
L’inconvénient est qu’on a probablement perdu 99% des utilisateurs métiers du back office. Pour modifier un élément, il faudra faire appel aux développeurs.
Alors, en synthèse ?
C’est un vrai sujet, il faut voir au cas par cas.
en fait, il y a toujours une limite, entre ce qu’on peut faire avec le back office, et ce qui doit être programmé. Certains systèmes essaient de repousser très loin la bascule vers la programmation, mais cette bascule existe toujours, et c’est pas prêt d’être fini : je ne crois absolument pas en « la fin de la programmation » avec la « programmation graphique » type UML… C’est un leurre marketing !
Quelques idées en vrac :
- Si il s’agit d’une opération répétée régulièrement par les utilisateurs du back office, pas d’hésitation, il faudra une interface, et plus l’opération sera répétitive, et plus l’interface devra être soignée, pour faire gagner du temps aux équipes ;
- Si l’interface s’avère très complexe, il arrive que la question prenne du sens : développer l’interface peut être très coûteux, et finalement pas rentable du tout, parce qu’en réalité, les utilisateurs n’utiliseront pas cette interface. Exemple : qui utilise un modeleur de processus d’un ETL ? Des informaticiens, qui iraient bien plus vite en programmant…
- Si on doit « modeler » un problème via un langage de programmation, il est fondamental de développer des couches qui permettent d’exprimer le problème avec un bon niveau d’abstraction. C’est très important, parce que sinon, la mise à jour du programme sera compliqué, cher, … On ne fait pas toujours ce travaille, et c’est un vrai problème !
Il faut prendre en compte également les compétences des équipes qui sont amenées à travailler sur ce back-office. J’ai tendance à penser qu’une interface bien pensée permet à une équipe d’être plus indépendante vis à vis d’un prestataire et lui donne beaucoup plus de réactivité, mais à coté de ça, ca fait peser plus de risques quant à la bonne marche du site puisque les utilisateurs sont susceptibles de générer des erreurs (une mauvaise valeur dans le module de gestion des promotions et c’est le drame…)
Donc ca veut dire qu’il faut rajouter des couches de contrôles pour s’assurer que ce que fait l’utilisateur est « correct » voir même un workflow de validation et de mise en ligne… Et puis on s’aperçoit que ça commence à chiffrer et qu’il vaut donc mieux continuer de laisser faire des programmeurs !
@Nicolas> Rien à ajouter 😉
Concernant votre exemple de l’interface des règles de promos Magento, je ne suis pas forcément d’ailleurs.
Alors effectivement, c’est « facile » de configurer une nouvelle règle mais impossible d’avoir par exemple la prévisualisation des conséquences de ces règles.
C’est très bien pour une société qui gère ses promos et sa marge en amont mais pas pour une société qui utilise Magento pour tout faire.
@Edouard> Complètement d’accord !
Ce qui m’a marqué par ce système, c’est sa souplesse, mais après, sa réelle « utilisabilité », c’est un autre sujet !
Encore un outil pensé par des techniques pour des personnes du marketing…