Skip Be in contact

Be in contact

Skip The companySkip Main MenuSkip Course categoriesSkip Technical description of services

Pourquoi croire en l'open source ?

Parce qu'avec la mondialisation des communication et des réseaux, la confrontation des solutions pour régler un problème informatique permet de réunir suffisamment de forces pour créer une solution consensuelle, parce que forgée par ses utilisateurs

Parce qu'une équipe de contributeurs, à la fois producteurs et consommateurs de leur production produit une force de travail infiniement supérieure à tout service de R&D internalisé dans une entreprise.

Parce qu'une économie positive ne recherche pas nécessairement le rapport de force, un perdant et un gagnant, mais plutôt la création d'une nouvelle valeur par la coopération des forces. L'open source transcende ce principe à une échelle sociale.

Parce que l'informatique est aujourdhui proche de l'utilisateur, doit en servir les besoins directs ici et maintenant, elle est au service du plus grand nombre, et non plus d'un collège d'experts en blouses blanches. Elle doit s'adapter, s'humaniser, s'anthropologiser. L'open source maîtrisé ne coûte que le passage du générique au contextualisé, en évitant le piège du spécifique.

Code source ouvert (open source) et gratuité

La confusion est fréquente entre open source et "gratuit". Si open source dit que le créateur du logiciel laisse un accès au code source à l'utilisateur pour que ce dernier puisse améliorer le programme, l'usage du source, de la licence d'utilisation n'est pas nécessairement gratuite.

Dans le même ordre d'erreur, un code source ouvert ne coûte pas rien à produire. C'est soit le premier commanditaire qui a payé le développement, soit son coût a été disséminé sur toute la chaîne de contributeurs. La plate-forme d'enseignement en ligne Moodle a été estimé aujourd"hui à 15 M$ s'il fallait prendre une équipe d'ingénieurs et tout reconstruire. Les revenus progressifs et les dons et contributions ont permis de couvrir en partie ce coût. Les institutions utilisatrices ont collectivement financé indirectement ou directement le reste. A l'arrivée, la mise en place de la plate-forme coûte BIEN MOINS CHER que si chacun avait construit son propre système, avec un degré de qualté et de finition infiniment supérieur. 

Intégration et développement

Un projet informatique peut se faire par deux approches radicalement opposées : l'intégration et le développement. Le développement est l'ancienne méthode, à une période où il n'existait que peu de partage des résultats techniques de chaque développement. Il convient à des produits très spécifiques ou complètement innovants.

L'intégration modifie des open source ou progiciels ouverts pour aboutir à l'objectif. En désossant une technologie qui apporte déjà l'ensemble des solutions, on amène un "all-in-the-box" à faire le juste nécessaire. Les approches intégratives seront alors à choisir entre l'approche "intégrée" et l'approche "modulaire".

Le développement ajoute des fonctionnalités au fur et à mesure du travail des dévelppeurs. L'intégration en enlève ou en modifie :

Bénéfice de l'intégration

Si l'on trouve un point de départ le plus proche (B) de son objectif, le temps de mise en opération peut être considérablement optimisé.

Approche "intégrée" ou "modulaire"

Lorsque l'on choisit la voie de l'intégration, il s'agit de trouver une technologie qui fournir le plus d'éléments qui répond au projet de construction du système d'information. Parmi ces solutions, on trouvera une approche "intégrée", dans laquelle les relations entre les différentes parties ou sous-ensembles sont riches : tout est connecté avec tout et peut tirer parti de cette connaissance globale et intime. L'intgération de système intégrée consiste le plus souvent en "paramétrage" pour "élaguer" les fonctions non nécessaires (les cacher) et en la fabrication d'une couche très externe de présentation de ce qui reste (des templates).

L'approche modulaire reprend l'idée constructiviste du développement, mais au lieu de partir de rien, dispose à la base :

  • d'une infrastructure modulaire
  • d'un ensemble de modules

Parfois, une distribution "minimale" permet de démarrer la solution sans aucun travail d'intégration (Moodle en fait partie).

L'approche modulaire rend plus difficile "l'intégration totale", c'est-à-dire une réponse immédiate à n'importe quelle combinaison de données ou de services, car les modules, en général développés par des équipes séparées, ont leur propre logique locale, et ont une "enveloppe" externe limitée à leur relation à l'infrastructure modulaire. Pour des raisons souvent économiques et pragmatiques, il est rare que des modules puissent prévoir ou anticiper toutes les coopérations possibles. Il serait même bien difficile de prévoir des coopérations avec des modules non encore développés ! 

Last modified: Tuesday, 12 July 2011, 04:55 PM