Quel est le problème de la certification d’un logiciel ? C’est que la certification ne peut être qu’une image à un instant particulier de l’état du code du logiciel et ne peut tenir compte de ses évolutions futures. Dans le cas des logiciels de caisse, ce qui est doit être audité, c’est le fait de s’assurer que le logiciel satisfait « à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale » (source: LOI n°2015-1785 Article 88).

Or, comme tout le monde le sait, un logiciel est nécessairement amené à évoluer (progrès technologiques et évolutions des pratiques). Il doit s’adapter à son environnement (sécurité, normes, métiers), il doit évoluer (correction de bugs, ajouts de fonctionnalités). Pour les éditeurs les plus actifs cela signifie des mises à jour régulières. Dès lors, qui peut certifier que chaque nouveau patch n’introduise pas une fonctionnalité contradictoire (même involontairement) avec la certification elle-même ? Un logiciel doit-il être « re-certifié » à chaque publication de mise à jour ? Ce sont les « mauvais » éditeurs, ceux qui ne tiennent pas à jour leur solution, qui seraient alors favorisés par cette loi !

Cet article de loi, cette certification, sont incompatibles avec la nature même du développement de logiciels de qualité. Volontairement nous ne parlons pas de logiciels libres pour le moment car tous les logiciels sont concernés. Qu’il s’agisse de logiciels libres ou non, un logiciel doit vivre et évoluer ; les éditeurs propriétaires seront confrontés aux même problématiques que les éditeurs Open Source ou les éditeurs de logiciels libres.

La vraie question au fond est :
Comment rendre le code des logiciels auditable facilement ?

Read More