Les deux leaders sur le marché de l’ERP sont SAP, n°1 incontesté made in Germany, lourd et ruineux, et l’américain Oracle Applications, un cran en-dessous en terme de marché, chiffre d’affaire et fonctionnalités, mais qui achète à tour de bras pour rattraper son retard. Les autres ne comptent pas, ont un marché de niche, ciblent les PME, ou ont été rachetés.

SAP existe depuis plus longtemps que moi, tandis qu’Oracle a longtemps basé sa réputation sur sa base de données qui, malgré bien des défauts, est devenue la référence dans le domaine. Si je parle d’Oracle ici, j’entends Oracle Applications, pas la base de données[1].

Je connais principalement Oracle Applications 11.0 et 11i, et, avec beaucoup moins d’expérience SAP R/3 et un peu le SAP CRM. Ce qui suit peut être dépendant du paramétrage des bases que j’ai rencontrées.

En passant d’Oracle à SAP, on s’aperçoit que la philosophie des deux produits est totalement opposée, même s’ils tentent de répondre aux mêmes besoins (gérer une entreprise de bonne taille de bout en bout) avec les mêmes moyens (beaucoup de MHz, de Go et de frais en licences et consulting).

C’est hideux

L’interface est aussi hideuse et anti-ergonomique chez l’un que chez l’autre, mais d’une manière totalement différente. En fait, ni l’une ni l’autre n’a vraiment évolué depuis au bas mot 1998.

  • Oracle semble avoir dix ans de retard sur le développement des interfaces graphiques à la Mac ou Windows. L’entreprise n’est pas connue pour son souci de l’ergonomie de toute manière.
    Depuis environ l’an 2000, l’utilisation de Java pour toutes les interfaces graphiques (de l’utilisateur de base à l’administrateur de la base) se traduit par une lourdeur certaine (plus supportable sur les machines actuelles), et un manque de cohérence avec les applications habituelles dans le monde Windows.
    L’essentiel de l’ERP est resté au paradigme des fenêtres qui s’enchaînent, se chevauchent... en mode MDI (des fenêtres dans la fenêtre principale, très à la mode sous Windows 3.1).
    Pour basculer d’une fenêtre à une autre (par exemple avoir des informations sur un article depuis l’écran d’une commande), le plus simple est encore de noter sur un papier ou dans le presse-papier ce qu’on cherche, de refermer toutes les fenêtres du module fonctionnel (!), et d’aller dans l’autre module...
    Le passage d’une partie de l’interface au mode web est déjà effectif mais son ergonomie est pour le moins perfectible. Oracle a l’intention d’évoluer vers un modèle mixte moitié « classique » (serveurs en entreprise, licenses...) moitié « à la demande», ie hébergé, par le web (un peu comme Salesforce).
  • SAP affiche ouvertement ses origines sur gros systèmes à une époque où l’idée d’un ordinateur sur chaque bureau relevait de la science-fiction sinon de l’utopie. Les « listes » brutes existent encore, avec les tableaux dessinés à coup de caractères de contrôle, qui autrefois s’affichaient sans doute sur un bel écran de terminal noir et vert (sinon sur du listing papier).
    Le flux se base sur une succession d’écrans qui occupent toute la fenêtre, comme une page web, et pas comme des fenêtres séparées. À l’usage, ce n’est pas si mal.
    Depuis le texte a été enrobé, d’absconses icônes sont apparues, quelques gadgets sont sympathiques (notamment le double-clic pour accéder à une autre information, très pratique... quand il est là), mais l’interface ferait hurler n’importe quel ergonome. Par exemple certains onglets ont l’apparence de boutons d’actions (les onglets dignes de ce nom existent aussi) : Commande client SAP

Des limites énervantes partout

Les limites abondent chez l’un et l’autre, qui auraient apparemment pu être levées avec un peu d’effort (mais elles sont là depuis des lustres). Quelques exemples graves ou minimes, comme ils me viennent :

  • Le menu principal d’Oracle est du texte sous forme de menu (moche mais fonctionnel), restreint à la « responsabilité » (en gros, un module fonctionnel plus ou moins personnalisé) en cours. Les raccourcis qu’on peut y placer sont limités à dix (10), numérotés de 0 à 9. Supprimer l’un d’entre eux revient à renuméroter les autres.
    Écran principal Oracle
    Avoir plusieurs sessions simultanées d’Oracle Applications est possible en se reconnectant plusieurs fois.
    À l’inverse, SAP offre un menu avec tous les écrans autorisés à l’utilisateur, plus les « codes transactions » (taper VA03 pour lire les commandes, VF01 pour créer une facture...), et la gestion simultanée de plusieurs écrans (« modes ») est facilitée.
  • Les raccourcis clavier sous Oracle sont assez pauvres ; sous SAP l’usage des touches de fonction est massif mais le raccourci pour une même fonctionnalité change suivant l’écran.
  • Les raccourcis n’ont souvent pas grand-chose en commun avec ceux répandus sous Windows ou ailleurs.
  • SAP prend un malin plaisir à rendre difficile le pointage de souris. Les boutons de boîtes de dialogue sont petits, les boutons par défaut ne sont pas plus grands que les autres, et, cerise sur le gâteau, une grosse icône SAP remplace les habituels trois petits boutons Réduire/Agrandir/Fermer de toute fenêtre de Windows, lesdits boutons étant décalés plus à gauche, en réduction, pour bien être sûr de mal viser. (Voir copie d’écran ci-dessous.)
    Oracle n’a pas ce défaut, les boutons sont moches mais décemment dimensionnés. Par contre, inutile de chercher à agrandir ou réduire une fenêtre pour avoir plus de colonnes/lignes à l’écran, ce n’est pas prévu.
  • Nombre des écrans d’Oracle sont accessibles en écriture comme en lecture, pas de juste milieu (apparemment et simplement en tout cas). Dans le cadre de la restriction généralisée et paranoïaque des accès (Sarbanes-Oxley et tutti quanti), c’est très gênant.
    SAP a généralisé (au moins dans les vieux modules) le principe de transactions (entrées de menu) différentes selon qu’on veut créer, modifier, ou juste voir, une commande, un article...
  • La traduction française est désastreuse sur SAP (je connais Oracle surtout en version originale). La grammaire est correcte, mais je comprends souvent mieux en version allemande ou anglaise, un comble ! Entre autres détails : en français, on dit « Annuler » pour sortir sans rien faire d’une boîte de dialogue (comme en anglais : “Dismiss” ou “Cancel”), pas « Interrompre » (»Abbrechen« en allemand) !
    Que des morceaux d’allemand surnagent par-ci par-là dans les modules techniques, ou que des morceaux de phrases aient sauté de-ci de-là, est paradoxalement moins grave.
  • SAP abuse des abréviations dans les noms de colonne ou de champ, jusqu’à l’absurde (« C. » comme nom de colonne !). Y compris dans les infobulles, sisi.
    Oracle connaît peu les infobulles mais en général remplit moins ses écrans.
  • L’aide en ligne des deux concurrents pèche de la même manière : correcte dans un sens descriptif, insuffisante comme base de travail pour chercher comment retrouver ou paramétrer tel ou tel objet (il faut reconnaître que l’exhaustivité serait titanesque à obtenir).
  • (SAP) Pour imprimer une facture, il ne faut surtout pas cliquer sur le symbole vert qui signifie « OK » dans la boîte de dialogue après un clic sur « Éditer », mais sur l’icône de l’imprimante. Le bouton vert ne sert à rien !Édition de facture sous SAP
  • Pour le développeur : dans l’éditeur de code ABAP (imposé, oubliez Eclipse, vi, nedit...), les commentaires sont en bleu... s’ils sont déclarés avec une étoile sur le premier caractère de la ligne. Si le commentaire se trouve sur la même ligne que du code, séparé par un ", ils ne bénéficient pas de la coloration syntaxique !
    On prend donc vite l’habitude d’aérer le code ABAP (déjà très verbeux) par des commentaires seuls sur leur ligne. Ce n’est pas si gênant, car de toute façon l’éditeur ne supporte pas les lignes de plus de 72 caractères (le standard en 1983) !Éditeur ABAP
  • SmartForms, un module de SAP de développement de formulaire[2] possède des fenêtres avec ascenseur au sein d’autres fenêtres avec ascenseur ! Une monstruosité ergonomique que je n’ai jamais rencontré qu’au sein de pages web qui n’avaient pas le choix de faire autrement. Smartforms n’est pourtant pas un vieux clou traîné depuis vingt ans, mais un outil très récent de SAP - ce sont souvent les pires (en complexité inutile surtout).
  • Smartforms (encore lui) ne gère pas les différentes versions d’un objet, alors que la notion de gestion de versions est intégrée à l’éditeur des programmes ABAP depuis des années. Au passage, cela rend cauchemardesque la simple annulation de modifications... Chaque outil de développement a été ajouté sans grand respect pour la cohérence avec les outils précédents.
  • Etc. etc.
    Ce ne sont que des détails, mais mis bout à bout ils me tapent sur les nerfs. Ils résument bien la philosophie des produits et la manière dont il sont conçus et vendus.

Quelques gadgets sympas

C’est surtout SAP qui les possède (Mise à jour de 2008: voir aussi ce billet ) :

  • le double-clic déjà évoqué pour avoir plus d’information sur tel ou tel objet (mais il n’est pas toujours là) ;
  • les matchcodes, des petits sous-écrans qui permettent de faire des sélections de plages de valeurs un peu tordues (du genre « prendre les codes articles 1023 à 8123 sauf les 4526 à 5622, et pas le 8001 »), et bien intégrés au langage ABAP sous-jacent ; Oracle ne connaît que les plages de valeur simples ;
  • SAP mémorise les dernières valeurs entrées dans un champ ; si vous manipulez les dix mêmes articles/commandes/programmes, ils sont automatiquement proposés dans un menu déroulant à chaque saisie ;

Partie 1 : Des interfaces hideuses

Partie 2 : Deux gros patchworks

Partie 3 : Des interfaces très particulières

Partie 4 : Philosophies opposées

Partie 5 : Schémas de données

Notes

[1] De toute façon, SAP utilise en général Oracle (la base) en arrière-plan...

[2] Dans le sens « bout de papier à imprimer » ; pour compliquer les choses, les terminologies de « rapport » et « formulaire » sont à peu près opposées entre les deux concurrents...