Programme d’innovation all-in-web

Le programme d’innovation de all-in-web entre 2015 et 2019.

Cet article est un compte-rendu de notre programme de recherche et développement, compte-rendu destiné à partager les connaissances acquises avec d’autres entreprises ou organismes. Ce programme de R&D a reçu une aide sous la forme d’un CIR et d’un CII.

Genèse du besoin d’un nouveau type de progiciel innovant

L’historique et la prise de conscience du besoin d’un nouveau type de logiciel en ligne remonte aux années 2014-2015. Depuis sa création all-in-web en 2005 avait développé sa plateforme applicative incluant un backoffice qui peut s’apparenter à un ERP dans une logique de produit logiciel (progiciel) standard en mode Saas. Ce logiciel, déjà innovant à son époque, s’était enrichi pendant 10 ans en fonction des besoins exprimés par les clients pour couvrir progressivement tous les besoins de gestion d’une structure associative ou d’une petite entreprise.

La limite rencontrée en 2014-2015 a été l’adaptabilité du logiciel à des contextes très différents. Faire rentrer dans un seul moule tous les cas spécifiques de tous les clients était devenu progressivement extrêmement problématique. Soit la structure applicative et celle de la base de données sont communes et le logiciel est peu souple soit la BdD varie en fonction du client et le code est truffé de « verrues » spécifiques. Continuer et garder la même plateforme conduisait à une impasse : ne plus répondre aux besoins spécifiques des uns et des autres ou avoir un programme difforme devenant ingérable d’un point maintenance industrielle.

Rappel sur les différences entre un logiciel spécifique et un progiciel.

- Un logiciel spécifique est développé, comme son nom l’indique, spécifiquement pour un besoin bien particulier et défini le plus souvent dans un cahier des charges ou une expression de besoin. On attend d’un tel logiciel des fonctionnalités précises et propres à un groupe d’utilisateurs. Ce « costume sur mesure » est donc parfaitement adapté pour un besoin donné et il concourt le plus souvent à une grande efficacité et productivité. Par contre il est totalement inutile et inadapté pour un autre client. Il n’est pas « industrialisable » et ne peut être « vendu » qu’au client maitre d’ouvrage. En cela il coûte cher en développement et surtout en maintenance (1 seul client). On estime en effet que la maintenance d’un logiciel spécifique coûte entre 8 et 12% de son coût de développement initial.

- Un progiciel à l’inverse est destiné à être utilisé par plusieurs groupes d’utilisateurs. Il est partagé et maintenu dans une perspective de mutualisation des besoins. Il n’y a pas de cahier des charges ou de spécifications mais un développement commun réalisé par l’éditeur dans l’espoir de satisfaire plusieurs clients. Au client de s’adapter au progiciel, et pas l’inverse. Par exemple un progiciel de gestion de paye va présenter un certain nombre d’écrans de saisie des éléments variables de paye, de workflow de validation, d’enregistrement dans la comptabilité, de déclarations fiscales…. En cela il est beaucoup plus économique : étant déjà développé pour d’autres, l’éditeur ne fait en général payer qu’une licence d’utilisation au démarrage et le coût de maintenance est mutualisé.

Mais des exemples dans de grands Groupes ou dans des Ministères ont montrés la limite de ces progiciels pour s’adapter à un environnement plus complexe et plus spécifique.

La synthèse, sous forme d’oxymore : un progiciel industriel, générateur de logiciels spécifiques.

L’innovation recherchée peut se résumer en quelques points :

- être fondamentalement un progiciel industriel avec une seule maintenance mutualisée, et qui peut être diffusé auprès d’un grand nombre de clients différents. Une équipe de développeurs « back-end » développe et enrichit les possibilités du progiciel sans jamais introduire de code spécifique pour tel ou tel client

- pouvoir construire avec ce progiciel, des logiciels spécifiques adaptés à des clients différents ayant des besoins différents. Le progiciel en ce sens est un générateur d’applications.

- pouvoir élaborer avec ce progiciel une bibliothèque de logiciels standards qui serviront de base pour construire tel ou tel logiciel spécifique.

- le progiciel est en 100% internet (aucune installation de « client » sur le poste de travail) et en vrai « vrai » mode Saas (par opposition au mode hébergé) : à un moment donné i n’y a qu’une seule version du code qui « tourne » pour tous les utilisateurs.

Les difficultés rencontrées

- comment avoir une gestion de base de données unique, un stockage virtuel, sans connaitre à l’avance les éléments de données qui seront utilisés pour une « Instance » donnée d’un client ?
- comment bénéficier d’une logique de progiciel et de BDD commune et d’une déclinaison par client complétement variable ?
- comment conceptualiser à l'avance de manière générique tous les objets et traitements qui seront nécessaires pour adresser les besoins spécifiques ?

L’état de l’art.

Notre progiciel-logiciel est en quelque sorte un générateur d’application comme par exemple Ms-Access. Mais avec une technologie différente (mode Saas, logiciel internet, multi-utilisateur, responsive design etc…) et avec une autre différence fondamentale : il ne nécessite pas « d’informaticien » ou de programmeur " back-end " pour créer une application.

Les Recherches menées sur ce sujet ont conduit à nous montrer que si le sujet était largement discuté dans la communauté des architectes de données et d’applications, aucune solution n’existait vraiment pour concilier cette notion de structure de "User Defined Field" avec une logique de maintenance industrielle et unique d’un progiciel.

Le problème se complique et n’a pas vraiment de solution aujourd’hui s’il s’agit - non pas de rajouter un simple champ spécifique utilisateur (ce que beaucoup de progiciel font y compris notre version actuelle de all-in-web) - mais d’autoriser une structure de données spécifique.

Prenons un exemple avec un « objet adresse ». Il s’agit de permettre à l’utilisateur de personnaliser un item adresse avec les champs qu’il souhaite sans toucher à l’architecture applicative. Que ce soit le même code progiciel qui puisse gérer des structures d’Item différents d’un client à l’autre.

En développant plus loin le concept, est-il possible de proposer un progiciel avec une maintenance et un versioning (Maintenance évolutive) standard tout en autorisant des fonctions ou des applications spécifiques utilisateurs ?

Est-il possible d’avoir des Fonctions spécifiques dans un progiciel ?

« In SQL databases, a user-defined function provides a mechanism for extending the functionality of the database server by adding a function that can be evaluated in SQL statements. The SQL standard distinguishes between scalar and table functions.»

« A scalar function returns only a single value (or NULL), whereas a table function returns a (relational) table comprising zero or more rows, each row with one or more columns.»

Les objectifs du programme d’innovation de all-in-web

Partant des résultats du programme de Recherche de 2016, le programme d’innovation, commencé en janvier 2017, s’est donné comme objectif de construire un pilote significatif du projet ACME et de montrer ainsi la faisabilité des concepts définis plus précisément dans le document « Programme de Recherche : projet ACME » :

• Le site
• Le formulaire (Node)
• L’Item (boite)
• La structure de données flexible
• Les types de champs adaptés
• Les relations entre items
• La publication via URL
• Les adjectifs/propriétés de chaque niveau
• Adresse URL
• Evénement (exécution d’une action en fonction d’un déclencheur)
• Composant (bloc)
• Vue (Mise en page)

Compte tenu de l’ampleur du projet, les éléments suivants ont été abordés dans un 2ème temps :

- La notion d’interface (API),
- Le multilangue
- Les interactions sociales
- Les dates de publication et d'expiration
- L’accès public ou privé
- La notation et les commentaires

Les choix technologiques retenus :

- Plateforme : Linux Debian 8
- Serveur web : node.js
- Base de Données : PostgreSQL
- Langage de script : javascript
- framework JS : jquery / riot.js
- moteur de template : EJS
- Framework CSS : Semantic UI

Les enseignements

Notre expérience montre qu’un tel progiciel est possible et qu’il apporte une énorme souplesse et une grande maintenabilité par rapport aux demandes spécifiques des clients.

Exemple de fonctionnalités qui ont été « développées » (paramétrées) grâce à ACME sans aucune intervention des développeurs :

  • gestion des congés,
  • gestion des notes de frais,
  • gestion de projet,
  • enregistrement d’écritures comptables,
  • « logiciel » de facturation,
  • Etc…

Un nouveau métier

Les leçons à tirer de notre expérience et qui peuvent servir être utiles pour d'autres éditeurs :

  1. tout d'abord et tout simplement, c'est possible : avoir à la fois un progiciel industriel et des applications adaptées pour chaque client est faisable. Cela nous a coûté 3 ans de recherches, d'essais, de développements, d'efforts mais maintenant mais il est sans doute possible pour d'autres éditeurs de faire plus vite maintenant que la voie est tracée
  2. la clé de la réalisation concrète de l'innovation a été de conceptualiser les composants clés permettant de générer une application : un exemple concret est la notion d'événement : une action, variable, qui peut être déclenchée en fonction d'un déclencheur ("trigger") qui peut être une modification ou une création de donnée. Cet "objet" est la clé de voute permettant de construire un workflow
  3. un métier nouveau apparaît qui est intermédiaire entre du développement et celui du paramétrage : le gestionnaire d’application, celui qui à partir des demandes clients créé l’application demandée en « jouant » uniquement avec la structure des données
  4. le retour du cahier des charges : alors que pour un progiciel "standard", on "prend ou on laisse" et que l'acheteur ne fait pas de cahier des charges et se contente de vérifier l'adéquation de son besoin avec le logiciel, ACME remet le cahier des charges à l'honneur. Le client peut ainsi définir les fonctionnalités souhaitées
  5. la baisse des prix : comme expliqué plus haut un logiciel spécifique réalisé une fois pour un client coûte plus cher qu'un progiciel. ACME permet de réalisé un logiciel dédié pour à peine plus cher qu'un progiciel.
  6. une limite cependant pour ACME pour réaliser n'importe quelle applications qui autrefois aurait demandé un développement spécifique : l'UX. Il n'a pas été possible de permettre n'importe quel interface utilisateur et il a fallu définir une présentation standard des écrans. En contrepartie cet UX a repris ce qui se fait de plus intuitif et de plus actuel aujourd'hui pour les applications en ligne.
  7. la performance : les "composants" élémentaires de ACME qui permettent de construire des applications dédiées sont optimisés de manière à permettre une gestion de gros volumes de données : un essai a été effectué avec une base de données de plus de 1 millions de contacts avec des temps de réponse de moins de 1s.