L'histoire de StorgaLe mur de verre de la programmationSi Pliant représente une avancée majeure pour des développeurs d'exception en termes de productivité, du fait de la suppression des incohérences et limites en termes d'expressivité qui nivelaient la productivité par le bas, en revanche, on reste dans un système de développement traditionnel, donc on retrouve les limites traditionnelles :
Storga est né comme le complément de ce super outil de développement. Quand pour les raisons qui viennent d'être citées, on ne veut pas lancer de développement, qu'est-ce que l'on fait ? Le point de départ de Storga, c'est donc un cahier des charges visant à maîtriser la complexité. Le cahier des charges de StorgaComme nous venons de le dire, le but était d'aller plus loin que Pliant en terme de réduction de la complexité. On a donc naturellement construit le cahier des charges par une simple inversion des limites précédemment rencontrées. Ce qui donne :
Et nous pourrions ajouter une quatrième contrainte qui s'est trouvée satisfaite de fait :
Ce qui fait que ce cahier des charges construit de manière un peu naïve est valide, c'est qu'il nous a guidé très efficacement, a été un bon fil directeur, pour passer de l'idée de départ au produit opérationnel qu'est aujourd'hui Storga. La naissance de StorgaStorga a commencé en 2010 comme un simple traitement de texte collaboratif auquel on a adjoint un système de formulaires libres, et de reporting simple de ces formulaires. Lors de cette première phase, les formulaires et états étaient principalement utilisés pour traiter la notion de projet. Quels sont les projets en cours, quels sont les projets gérés par chaque personne, qui a demandé quoi, quand, à qui ? Le système de fiches et états s'est avéré si pratique que l'on s'est mis à l'utiliser un peu partout : fiches contacts, notes de frais, puis écritures comptables. Au fur et à mesure de la multiplication des utilisations de Storga, les fiches se sont enrichies avec la notion de sous table, et sont devenues de véritables petits tableurs, mais toujours en veillant scrupuleusement à ne pas sortir du cahier des charges initial. Ensuite, en 2014, nous avons commencé à envisager en Storga des déploiements plus complexes qui nous ont montrés qu'en plus des fiches élémentaires et états qui les filtrent et les listent, on a besoin aussi de fiches de synthèse qui permettent d'appréhender l'activité à plus haut niveau, et qui sont donc l'outil de base de la consolidation. La gestion automatique des fiches de consolidation a nécessité une intense recherche pour ne pas sortir du cahier des charges initial, puis a montré la nécessité de faire monter l'outil en puissance pour pouvoir gérer non plus des milliers mais des millions de fiches. A partir de là, les conséquences se sont plus ou moins imposées à nous : nous sommes arrivés à développer, en suivant des chemins de traverse, non pas un produit de niche, mais un système central pour l'informatique de backoffice de demain, puisque représentant une amélioration significative en terme d'adaptabilité par rapport au modèle relationnel actuellement utilisé pratiquement partout. Nous y sommes arrivés suite à beaucoup de travail, et nous sommes persuadés que l'on ne peut pas y arriver directement par une idée géniale que l'on a un beau matin. Nous y sommes arrivés par hasard tout de même, ou plus exactement par tâtonnements successifs, car nous n'avions absolument pas une image claire au point de départ des dimensions du domaine d'utilisation que nous arriverions à satisfaire en respectant le cahier des charges initial. Aujourd'hui, la théorie qui soutend Storga, au sens de représentation des choses, est posée, et pourtant, nous continuons à expérimenter et découvrir ce qu'elle permet en termes de rangement automatique des données, ou de traitement automatique de fichiers. |