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 !
