Nous avons vu dans la page sur le budget que les difficultés actuelles, futures ou potentielles liées aux failles de sécurité avaient inquiété suffisamment d’informaticiens de la communauté généalogique pour qu’une solution de repli apparaisse nécessaire à court terme.

Compenser le vieillissement de logiciels nécessite de disposer de nouveaux outils (des anciens rénovés ou des nouveaux créés de toute pièce)  ; éviter l’isolement technique ou humain nécessite de mutualiser nos ressources et nos compétences.

Mais se pose alors la question de la démocratie interne du collectif. Bien sûr, le CIGen étant une association, l’Assemblée Générale y est souveraine. Mais cela ne règle pas tout : il faut notamment envisager comment les logiciels seront gérés.

Le groupe des fondateurs avait élaboré une vision de ce que cela pourrait être, de comment un collectif pourrait fonctionner. Mais cette vision pourra être modifiée selon les choix des adhérents. Nous l’avons affinée et nous vous la présentons ici.

Il faut tout d’abord considérer qu’il y a 2 contextes : il y a les logiciels que nous préconisons ou distribuons simplement, et ceux dont le CIGenassure le développement et la maintenance.

1. – Logiciels préconisés ou distribués

Nous parlons ici de logiciels que nous pourrions recommander ou pour lesquels nous obtiendrons un droit de mise à disposition de nos adhérents sans le droit d’intervenir dans le code.

Un exemple  ? Un outil de gestion comptable : le CIGen pourrait acheter une licence globale, ouvrant droit d’utilisation à chaque association adhérente, sans pour autant que nous disposions de la possibilité de modifier (corriger, changer) les programmes.

Nous aurions, en tant que distributeurs, un peu plus de poids qu’un simple utilisateur, mais au final nos possibilités d’impulser des évolutions seraient relativement modérées. Bien sûr, en contrepartie, l’investissement humain serait nul  !

2. – Logiciels distribués

Imaginons : le CIGen dispose d’un logiciel satisfaisant (il l’a développé, récupéré gratuitement ou en a racheté les droits). Ce logiciel gère des informations critiques pour les associations : leur portail (ce site ou partie de site où vous présentez l’association, de la documentation, des aides sur les méthodes, un journal…), leur gestion administrative (les adhésions, les paiements) et/ou la base de données des actes  ; quel que soit le domaine applicatif, ça ne change pas grand-chose.

Ce logiciel peut faire l’objet de maintenance corrective (une anomalie à corriger), de maintenance préventive (une contrainte technique à prendre en compte avant qu’elle ne pose problème) ou de maintenance évolutive (quelqu’un veut modifier le fonctionnement de l’outil ou ajouter quelque chose).

Globalement, les deux premiers types ne posent pas de problème démocratique : il est très probable (pour ne pas dire certain) que tout le monde sera d’accord pour réaliser les modifications nécessaires et ainsi assurer la continuité du logiciel.

Les évolutions sont plus sensibles.

Lorsqu’il s’agit d’ajouter une fonction, il y a des contraintes à prendre en compte : il ne faut pas que cette nouveauté perturbe ou empêche le bon fonctionnement des autres fonctions, utilisées par les autres associations qui seraient alors impactées. Globalement, une bonne approche architecturale (modularité et extensibilité diraient les informaticiens) permet de gérer ce risque.

La suppression d’une fonction repose sur les mêmes règles : soit c’est une fonction centrale que plus personne n’utilise et on la retire sans problème, soit c’est une extension optionnelle et chacun est libre de l’activer ou non. Le cas le plus sensible est une fonction centrale dont quelques associations ne veulent pas : il faudra alors les convertir en extensions optionnelles.

La modification d’une fonction est la plus sensible, mais là aussi, des solutions techniques sont habituellement possibles : vous connaissez tous les Réglages des Apps sur vos téléphones, qui permettent de bloquer ou non les correspondants inconnus, de personnaliser les couleurs ou la taille des caractères. On peut tout à fait disposer de réglages similaires pour une application de généalogie : je coche une case et l’option ’Utiliser les variantes patronymiques’ est activée : l’association qui a constitué une liste de variantes peut s’en servir pour faciliter les recherches d’actes  ; à l’inverse, celle qui ne dispose pas de cette liste décoche la case et tout se passe comme si le logiciel ne connaissait pas les variantes.

On le voit ici, la démocratie ne dépendra pas du potentiel de la technologie : sous réserve d’une architecture adéquate de nos logiciels, les besoins différents seront compatibles et combinables. Ceci, au passage, montre à quel point il sera critique que l’architecture des logiciels dont le CIGen gère le développement soient modulaires et extensibles…

Là où la démocratie aura à jouer, c’est sur l’économie des logiciels.

Les informaticiens du collectif assureront la maintenance corrective des logiciels. S’il leur reste du temps, ils pourront faire des évolutions, s’il ne leur reste plus de temps, il serait toujours possible de sous-traiter. La question est alors : qui choisit les évolutions que les informaticiens feront ou que le collectif financera  ?

L’un d’entre nous a travaillé comme Responsable Produit chez un éditeur informatique. La question était exactement la même : d’un côté l’entreprise voulait investir pour son logiciel s’adapte aux besoin du marché et de l’autre les clients déjà utilisateurs avaient des attentes, des demandes voire des exigences  !

La solution est assez classique : elle repose sur l’évaluation d’une part de la ressource disponible (combien d’heures les informaticiens sont-ils prêts à offrir dans l’année qui vient  ? de combien d’argent dispose le collectif pour faire appel à des sous-traitants  ?). D’autre part, elle nécessite une évaluation empirique du coût (humain et/ou financier) de chaque évolution souhaitée. Enfin, un groupe décide : l’évolution A, réalisée par les inf ormaticiens internes, coûtera 3 jours de travail sur les 5 disponibles  ; l’évolution B, sous-traitée à un centre d’infogérance, coûtera 12 000 € sur les 12 100 disponibles  ; les évolutions C et D ne seront pas traitées dans l’année à venir.

Nous avons vu que nos outils devront impérativement être modulaires et extensibles. L’extensibilité ouvrira en complément la possibilité pour une association (ou un groupe d’associations) de développer ou faire développer à son compte un module qui viendrait compléter les outils pour son usage personnel.

La démocratie s’exprimera dans l’évaluation des évolutions, dans le choix des évolutions, dans la procédure menant à ce choix, et dans le mécanisme de financement (qui évalue le temps disponible  ? qui évalue le temps nécessaire pour réaliser une évolution  ? qui en estime le coût  ? qui vote  ? une association qui cotise beaucoup a-t-elle plus de voix que celle qui cotise moins  ? l’urgence d’une évolution est-elle prise en compte  ? le CIGen demande-t-il chaque année une sur-cotisation pour avoir des réserves pour financer les évolutions si besoin ou est-ce que les demandeurs doivent apporter l’argent éventuellement nécessaire  ?).

Dans l’immédiat, la solution mise en œuvre au démarrage (et qui sera raffinée en A.G.) sera la suivante :

• Il faudra en premier lieu former les informaticiens aux différents logiciels et aider les premières associations dans la mise en production des outils choisis : cela consommera largement toutes les ressources humaines de la première année
• Dans le courant de cette première année, les demandes d’évolution seront collectées, et estimées (faisabilité, temps consommé…) par un comité technique, dont feront nécessairement partie les informaticiens dédiés au logiciel concerné
• En Assemblée Générale, chaque association sera invitée à voter pour les évolutions qu’elle souhaite. Classiquement, une association pourrait avoir 1 point pour 10 de ses adhérents et pourrait panacher ses points sur les évolutions qu’elle choisit. Le nombre de point pourrait être limité : aucune association ne peut disposer de plus de 40 % du total des points, pour éviter qu’une grosse association devienne hégémonique dans l’évolution des logiciels.

Ceci n’est bien sûr qu’une proposition de démarrage, l’Assemblée Générale décidera du fonctionnement qui sera réellement mis en œuvre.