Le W3C vient de placer XForms, technologie de formulaires électroniques, au niveau "proposition de recommandation". Mais Microsoft développe de façon concurrente sa propre offre : InfoPath.
Par Hervé AGNOUX, de la SARL diaam informatique.
mercredi 13 août 2003
La FAQ de Microsoft concernant InfoPath et les standards ne laisse guère de doutes : pour cette société, XForms est hors jeu. Parallèlement, au W3C, sur le site du projet XForms, la liste des mises en oeuvres de cette technologie ne cite aucun produit Microsoft, et surtout pas, bien sûr, Internet Explorer.
Ainsi les formulaires électroniques donnent la première occasion d'un affrontement Microsoft/W3C depuis longtemps. Si ce n'est pas encore une guerre, c'est au moins une escarmouche : les deux organismes jouent leur crédibilité sur la question.
Il existe bien sûr des différences entre les deux approches ; XForms se place dans la continuité des formulaires HTML, et InfoPath met l'intégration des processus de publication au centre de l'argumentaire marketing. Mais, globalement, il est bien difficile de voir ce que l'un peut apporter de plus face à l'autre, à part l'incompatibilité.
Les formulaires électroniques sont repérés depuis longtemps comme un enjeu majeur des niveaux métier de tout système informatique. C'est, par excellence, celui du e-commerce, et par extension, celui de l'EDI.
Et que ce terrain soit justement le terrain d'affrontement en dit long sur la volonté réelle des offreurs à normaliser les autres segments des niveaux métiers, à commencer par les services webs. Néanmoins, existe t'il actuellement un organisme en mesure de normaliser ce segment ? De quels relais réels dispose le W3C pour aborder les questions d'échanges électroniques ? Par delà les effets d'annonces, les technologies sont-elles vraiment matures ?
Alors que faire ?
Avec les formulaires électroniques, nous sommes de façon presque obligatoire situés à un niveau métier. Entre ce niveau, et celui de la mise en oeuvre technologique, il existe de nombreux niveaux et de nombreux critères de choix. Ni le choix "tout Microsoft", ni le choix "tout standard W3C", ni même "tout navigateur web" ne sont à priori donnés.
Même s'il existe des applications métiers sur l'Internet, ce type d'application se trouve plus sur des environnement type extranet. Il s'agit de groupes de partenaires engagés dans la réussite d'un projet commun. Depuis longtemps, ce niveau est contraint à une plus forte ouverture, parce que il n'est pas envisageable pour chaque partenaire de s'équiper en matériel propre à chaque communauté.
Aussi, il me semble important de toujours préférer les solutions basées sur des standards ouverts, à savoir, pour le sujet qui nous préoccupe, préférer XForms à InfoPath, ce qui revient à utiliser un autre navigateur qu'Internet Explorer. Dans le cadre des extranets, il est parfaitement envisageable de le faire, et cela peut même être mieux que de proposer des outils spécialement identifiés pour la communication partenaires.
Donc, oui : il faut recommander XForms.
Mais il ne faut pas en rester là, car la période trouble qui s'annonce sur les technologies web rendrait bienvenue une relance de la normalisation des métiers de l'informatique - méthodes de développement, justification des choix, etc - ainsi que des métiers utilisateurs. Concernant XML, par exemple, il existe peu de travaux sur les méthodes d'élaboration des vocabulaires. Souvent, on ne sait même pas donner la périphérie d'un métier donné. On commence juste à savoir passer de Edifact à un service web - lorsque quelqu'un le veut.
De plus, l'argument "standard ouvert" n'est pas suffisant en soi. Un thèse récente (L'usage du Flash et la standardisation des formats de publication sur le web) montre que des formats propriétaires peuvent avoir leur part dans des contextes particuliers, surtout lorsqu'ils parviennent au statut de standard de fait.
S'il faut recommander XForms, il ne faut pas oublier que c'est une technologie nouvelle, et que d'autres critères que le simple "standard ouvert" doivent être avancés pour justifier ce choix, critères fonctions du domaine de l'application à développer.
Proposer un formulaire électronique, ce n'est pas seulement donner des menus déroulants ; c'est également dire à un utilisateur final : "Attention, si vous appuyez sur ce bouton, vous allez déclencher..."
La suite n'est pas encore écrite.
Autres articles :
Copyright 2003,
Hervé AGNOUX.
|