Réglementation et logiciel libre, compatibles ?

Cet article a été publié il y a 6 ans 5 mois 13 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Peut-on utiliser des logiciels libres dans des domaines contraint par des réglementations et autres obligations légales ? Une question qui a été au cœur des échanges lors de l’apparition de la loi de finance 2016.

Certains termes de ce texte de loi pouvaient effrayer : inaltérabilité pour ne citer que celui-ci. Cependant ce critère concerne avant tout les données de l’application et pas l’application en elle-même.

Maintenant que ce texte de loi est en application,  comment répondre aux contraintes de la loi tout en préservant au mieux les libertés fondamentales des utilisateurs ?

Dans le cadre de cette fameuse loi de finance 2016, en tant que prestataire installant en dernier lieu l’application Dolibarr chez nos clients, c’est à nous que revient le rôle d’attester de la conformité de ce dernier aux critères d’inaltérabilité, de sécurisation, de conservation et d’archivage des données. Au cas où un client attesté venait à réussir à tromper le fisc malgré tout et se faisait prendre, nous serions co-responsable sur le plan pénal et financier de façon illimitée.

Vous comprendrez tout de suite qu’en tant que patron, cela vous fait quelque peu réfléchir avant de prendre la décision de signer une attestation. Il fallait donc trouver une solution permettant de « brider » les possibilités d’intervention sur le logiciel et la base de données. Avec un logiciel libre en PHP dont le code source est disponible, sans parler de la possibilité d’ajouter des extensions pouvant intervenir sur le comportement et la base de données, l’opération n’est pas aisée.

Malheureusement, la seule solution « fiable » que nous ayons trouvée est de fermer l’accès au code source et à la base de données (du moins en modification). En gros de faire une « boite noire ». Mais quand on a fait du logiciel libre et de ces valeurs son fer de lance, cela fait un peu mal au ventre….

Nous allons donc délivrer des attestations, mais uniquement dans certains contexte techniques précis : en hébergement sur notre infrastructure ou dans des machines virtuelles sur site auxquelles le client n’aura pas accès (du moins pas facilement…).

Pour préserver la possibilité de modifier soi-même Dolibarr, nous proposons un « sas » constitué par un dépôt sur notre instance Gitlab. Le client pourra ainsi proposer des modifications que nous pourrons auditer et décider d’intégrer a son instance Dolibarr de production.  La contrepartie sera hélas le coût, le temps passé à auditer restant facturé. Mais nous saurons rester « light ». L’idée n’est pas de se faire de l’argent facile sur le dos de nos clients. Les différentes possibilités et tarifs associés sont décrits sur le site d’Open-DSI.

Dans l’immédiat, nous n’avons pas de solution moins contraignante. Une externalisation de l’historique chaîné des transactions a été un moment envisagé, mais cela introduit tout de même des possibilités de « bidouillage » en amont.

Il n’en reste pas moins vrai que celui qui veut frauder trouvera le moyen. Le tout est qu’il ne puisse pas le faire via le logiciel que nous lui aurons mis à disposition.