Choix techniques

L'architecture

L'essentiel est d'assurer une stricte séparation entre le moteur et l'interface utilisateur. En d'autres termes, séparer le fond de la forme est la seule chance de préserver la simplicité du moteur et de lui permettre d'évoluer. Pour assurer cette stricte séparation, il faut dresser une couche entre le moteur et l'interface utilisateur qui assurera la stabilité du tout. Le moteur et l'interface pourront évoluer chacun de leur côté, tandis que la couche centrale évoluera plus lentement.

Parce que cette couche centrale est celle qui devra être la plus constante par la suite, c'est la conception de cette couche qu'il faudra dans un premier temps privilégier.

Le langage de développement

Trois langages ont été préselectionnés en fonction des affinités des participants au projet : Java, Perl et Erlang.

Un certain nombre de critères vont être envisagés pour réaliser ce choix :

Le caractère Open Source du langage

Perl et Erlang sont sans ambiguïté Open Source. Perl est disponible selon les termes de l' Artistic Licence. Erlang est depuis peu distribué suivant les termes de l' Erlang Public Licence, une adaptation de la licence de Netscape (NPL) à la législation suédoise.

Cette liberté assure une grande pérennité à ces deux langages, puisque qu'il est possible de disposer des sources et d'effectuer des modifications pour corriger des bugs ou bien améliorer les performances du langage. Par exemple, un groupe de développeurs peut développer un compilateur plus performant et cela de manière indépendante du projet principal.

Depuis peu, le statut de Java s'est clarifié et ce langage est maintenant clairement Open Source.

L'envergure du projet

C'est un des critères les plus décisifs, car la principale difficulté d'un projet de développement en gestion résulte dans le volume du code à gérer, lors du développement et surtout lors de la maintenance de l'outil.

Pour assurer la pérennité du projet, il faut un langage "structurant" qui incite à produire du code lisible et maintenable.

Sur ce point le caractère objet du langage Java le rend adapté à un développement de grande envergure. Il permet une bonne division du travail entre les développeurs grâce au principe de l' encapsulation. Des projets relativement volumineux sont envisagée dans ce langage (ERP: Movex Next Generation) sans qu'aucun résultat ne soit cependant visible pour le moment.

En revanche, la simplicité de Perl incite rapidement au quick and dirty. Il permet de faire des corrections ou des améliorations très rapidement, mais le volume du code est l'ennemi principal de ce langage. C'est a fortiori le cas pour une équipe de programmeurs bénévoles et éparpillés géographiquement (difficulté de coordination).

Erlang est utilisé sur d'énormes projets de développement dans le domaine des télécommunications. On dispose donc de la preuve de sa capacité à gérer de gros projets.

De plus, le caractère fonctionnel du langage et sa grande capacité d'expression lui permette de réduire le nombre de lignes de code nécessaires. Toutefois, cette compacité donne parfois un aspect peu lisible au code. Un peu d'habitude permet cependant de d'appréhender plus facilement un programme car ce sont souvent les mêmes schémas ("patterns") que l'on retrouve.

Facilité de développement distribué

En matière de réseau, Perl est essentiellement utilisé comme CGI (Computer Generated Interface). Cette utilisation se caractérise par une très forte centralisation des programmes, de l'information et des traitements sur une machine serveur, accessible par des clients légers. Il ne s'agit pas réellement d'une conception distribuée du développement.

Java dispose des RMI (Remote Method Invocation) pour mettre en place des techniques de développement distribué. Leur utilisation est lourde. La conception d'un programme monoposte diffère beaucoup de celle d'un réseau distribué.

La conception d'Erlang, à l'inverse, permet d'envisager la parallélisation des taches de manière simple. L'approche objet est utilisable, même si le langage n'offre pas tous les mots-clés. Un développement structuré dans ce langage pourra dès lors être distribué par nature. Il pourra même intégrer des techniques de répartition de charge entre différents serveurs dans le système.

L'accès aux bases de données

Le langage Java dispose de nombreux outils d'accès aux bases de données, grâce à l'interface JDBC et à l'existence de drivers pour toutes les bases de données relationnelles.

Il dispose de bibliothèques commerciales permettant d'asseoir le projet sur une conception objet pure et de déléguer les problèmes de stockage des objets à ces bibliothèques ("persistance"). Le problème est que ces outils sont commerciaux et que le développement de produits de substitution libre mobiliserait la totalité des développeurs du projet pendant une très longue durée. L'objectif du projet serait ainsi complètement détourné par des considérations techniques, ce qui limiterait l'implication des gestionnaires.

Perl offre des bibliothèques classiques d'accès aux bases de données relationnelles. L'accès aux bases de données libres (PostgreSQL) ou gratuites (MySQL) est possible. Mais ces bibliothèques sont relativement lourdes à mettre en oeuvre. L'accès aux bases de données en Perl est plutôt adapté à des taches d'administration système qu'à du stockage de données très structurées.

Erlang dispose d'une base de données libre intégrée à sa distribution. Elle est utilisé essentiellement pour un traitement des données en mémoire. Elle est donc peu adaptée à des modes de fonctionnement demandant des accès fréquents au disque. Les temps de réponse sont toutefois très faibles une fois la base montée en mémoire. Le langage dispose également d'une bibliothèque d'accès à Oracle, qui permettrait de prendre le relais pour le stockage de certaines données sur le disque. Une solution mixte Mnesia/Oracle est envisageable dans un premier temps. Par la suite, un portage de l'interface vers une base de données libre pourra être envisagé.

La fiabilité

Le choix de Java reste encore de ce point de vue problématique, en raison notamment de l'importance de la version du JDK utilisé.

Le choix de Perl est relativement neutre. La fiabilité dépend de la qualité de la programmation, mais on a vu que celle-ci risquait de décroître fortement avec l'augmentation de la taille du projet.

Le choix d'Erlang permet une conception tendant vers un très haut niveau de fiabilité. Notamment, il dispose d'outils pour gérer une hiérarchie de processus de supervision contrôlant le déroulement de processus productifs. De manière sous-jacente au langage, il existe un framework permettant de mettre en place des systèmes à forte disponibilité (24h/24, 7j/7).

Il permet également de mettre en place des solutions temps réel, qui peuvent être un atout pour le développement de certains aspects, liés par exemple à la logistique, à la prise de commande, etc. C'est le cas en particulier pour les tâches qui nécessitent la surveillance de valeurs seuil (par exemple, signal au service achat lorsque les stocks d'un produit descendent sous un certain seuil).

Le partage de code avec d'autres projets

Le projet Linux Kontor est le seul projet similaire existant. Il est développé en Java, en utilisant RMI comme méthode de développement distribué.

Le choix de Java permettrait de partager du code avec ce projet, voire de fusionner les deux initiatives. Cependant, ce projet vise essentiellement à copier des produits existants sans prendre en compte les attentes des utilisateurs de la prochaine génération d'outils de gestion. Son choix en terme de langage et d'architecture devrait rendre très difficile les évolutions du projet. Linux Kontor se trouve donc ancré dans ses choix initiaux et les possibilités offertes par le langage Java pour s'en écarter sont minces.

Pour faire ce choix de l'ouverture, il faut pouvoir utiliser du code disponible dans plusieurs langages et pas seulement du code Java. Dans ces conditions, le choix de Erlang est également un bon choix puisqu'il permet d'utiliser du code Java ou C et de les gérer comme un processus classique.

En outre la grande capacité d'expression d'Erlang et son caractère très modulaire en font non seulement un langage de production mais également un langage adapté au prototypage. Refaire certains modules qui auraient pu être mal conçus à l'origine n'est pas un frein majeur. Un projet de développement en gestion s'entend nécessairement sur la durée et doit prendre en compte des facteurs encore inconnus.

Le caractère multiplateforme

Les trois langages sont théoriquement multiplateformes. En pratique, le caractère Open Source du langage resurgit ici. Perl et Erlang étant réellement Open Source voient leur portage vers d'autres plates-formes facilité. Perl fonctionne sur des plates-formes très variées. Erlang est restreint pour le moment aux Unix et à Windows NT. Java fonctionne sur Linux, Solaris et les Windows 32-bits. La machine virtuelle java, jusqu'ici très fermée est cependant en train de s'ouvrir (Annonces de Sun, Annonce de Netscape sur le sujet).

On peut noter que Perl est disponible sur de nombreuses plates-formes et permet un accès via à un browser Web à ses programmes CGI. En revanche, le serveur Web utilisé doit supporter l'intégration de Perl. Ce n'est pas forcément le cas de tous les serveurs fonctionnant sous Windows NT.

Facilité d'installation

Perl a l'avantage d'être disponible en standard sur Linux. Un simple script permet ensuite de mettre en place le code du projet. Il faut cependant compter avec la nécessité de mettre en place un serveur Web et de configurer les CGI.

Java reste problématique du côté de l'installation. Les problèmes de version de JDK sont encore prégnants.

Erlang est relativement simple à compiler à partir de ses sources. C'est un système conçu pour être embarqué. Il dispose donc de procédures de «boot» qui facilitent le démarrage de l'application et de ses services.

La facilité d'administration

L'administration d'un système Erlang peut-être centralisée, alors même que l'exécution de ses programmes va être distribuée. Mettre en place les mêmes facilités en Java avec plus d'un serveur risque d'être relativement compliqué. En Perl, il en est de même et l'administration de plus d'une machine jouant office de serveur rend la tache assez complexe.

Conclusion

Le choix d'Erlang semble pour l'instant être le plus intéressant car il ne dispose pas de défaut rédhibitoire, mais offre en revanche des atouts uniques, notamment en ce qui concerne la programmation distribuée et la parallélisation des tâches.

Le choix d'un langage encore peu connu comme Erlang risque de rebuter un certain nombre de personnes. C'est cependant de moindre importance, si l'on considère le fort potentiel d'Erlang et sa relative facilité d'apprentissage.

D'autre part, le nombre ne fait pas la qualité. Vaut-il mieux attirer une dizaine de personnes compétentes et motivées ou bien un millier de contributeurs soumettant un nombre ingérable de petites modifications ?

Enfin, il faut bien être conscient que l'attirance de développeurs dépendra surtout du potentiel du projet et de la qualité technique et fonctionnelle des réponses qu'il apporte. C'est parce qu'il sera convaincu de la pérennité de son travail que le développeur pourra s'investir sans réserve dans le projet.

Questions / Réponses

Q: Le choix du langage est prématuré. Pourquoi ne pas poser le problème et choisir ensuite ?

R: Pour répondre à cette question, je m'appuyerais sur la méthode Merise. Le choix du langage peut intervenir très tôt dans le cycle de développement, au moment de l'étude préliminaire, à condition que ce choix puisse être considéré comme un choix stratégique pour l'ensemble du projet.

Envisager l'utilisation d'un langage de développement comme Erlang entre, je crois, pleinement dans ce cadre. Ce langage est suffisamment puissant, de haut niveau et dispose de suffisamment de bibliothèques pour permettre de réaliser les développements souhaités. Il est très expressif et permet ainsi de réduire le nombre de lignes de code dans le projet. C'est est point essentiel pour les projets en informatique de gestion où l'essentiel de la difficulté réside dans la manipulation d'un grand volume de code plus que dans la complexité des traitements à effectuer. Cette caractéristique laisse vraisemblablement entrevoir une maintenance facilitée. Erlang dispose de "comportements" standardisée permettant de structurer le développement et de construire des applications très fiables.

Enfin, un des éléments stratégiques les plus décisif est que ce langage permet de développer des applications distribuées de manière quasi-transparente pour le développeur et de manière très élégante.

De manière simplifiée, les premiers développements en gestion étaient basés uniquement sur les traitements. Il s'agissait de traiter des grandes masses d'information et de leur appliquer certains calculs de manière automatisée. Aujourd'hui, ce rôle est dévolu au système d'information se prolonge, mais la tendance est à l'intégration de fonctions "communiquantes". La tâche la plus importante dans le développement d'un système d'information n'est plus la réalisation des traitements, mais l'intégration de la notion de flux. Le problème n'est plus tant de savoir quel traitement de masse appliquer à tel ou tel type d'information, mais de modeler les flux d'information entre telle ou telle application ou entre tel et tel personne, etc. Cette modélisation des flux est de loin la tâche la plus complexe et pouvoir l'intégrer dans le développement est aujourd'hui indispensable. Pouvoir le faire au moindre coût en terme d'heure de développement est vital pour un projet libre, dont les ressources sont par nature très limitée.

Q: Pourquoi utiliser un langage dont la valeur stratégique apparait surtout sur d'énormes projets pour réaliser un petit module de rapprochement bancaire ?

R: Le délai de réaction d'une équipe de développement est parfois plus long que pour une société en terme de redéfinition des axes stratégiques. Pour assurer la pérénnité du projet, il est particulièrement important d'anticiper sur les futurs orientations et les futurs développement du projet.

Q: Avant de s'intéresser aux grosses PME et aux grandes entreprises, ne vaut-il pas mieux satisfaire les besoins des petites PME d'abord, puis ajuster nos ambitions ensuite et faire croître le projet ?

R: Lorsque l'on analyse l'offre et la politique commerciale des éditeurs, on constate que la différence entre un produit "light" (à destination des petites entreprises) et sa version "pro" (pour les plus grosses structures) réside en général dans la souplesse, la capacité d'évolution et de personalisation du comportement du produit.

Par conséquent, si l'on pense le projet comme directement modulaire et hautement paramétrables, il est possible de proposer un modèle de comportement standard satisfaisant les PME, tout en laissant de grande possibilité d'adaptation pour des besoins particuliers.

Cet aspect est rendu possible par la démarche originale du projet. Il ne s'agit pas de traiter de manière simplifiée toutes les fonctions informatiques à assurer par l'entreprise mais plutôt de ce concentrer d'abord sur certains de ces besoins et y répondre de manière complète. Il s'agit de développer des outils conformes à la philosophie Unix : Réaliser des programmes effectuant des tâches précises et capable de travailler sans problème avec d'autres outils conformément aux préférences de l'utilisateur.