Élaborer un cahier des charges pour les logiciels d'entreprise dans les PME suisses

L'utilité d'un cahier des charges pour les logiciels d'entreprise

Un cahier des charges – souvent appelé spécifications des besoins ou cahier des charges fonctionnel dans la pratique – définit ce qu'un logiciel doit être capable de faire. Il sert de base aux offres, au développement et à la réception du projet. Sans ce document, il n'existe aucune définition commune de ce qui constitue un projet « terminé ».

Les termes ne sont pas synonymes : le cahier des charges fonctionnel (Lastenheft) décrit le « quoi » du mandant, tandis que le cahier des charges technique (Pflichtenheft) détaille le « comment » du prestataire. Dans les projets de PME, les deux fusionnent souvent en un seul document. Cette approche est pragmatique, à condition qu'il reste clair de distinguer les exigences du mandant des solutions proposées par le prestataire.

La phrase « Je me l'étais imaginé différemment », prononcée à la fin d'un projet logiciel, coûte cher. Elle ne résulte généralement pas d'un mauvais travail de développement, mais du fait que les exigences n'ont jamais été formulées avec suffisamment de clarté. Comme les PME représentent 95 pour cent du paysage économique suisse (kmu.admin.ch), ce risque concerne la grande majorité des projets informatiques locaux.

Chiffres clés pour les PME en Suisse

Définir la situation initiale, l'objectif et l'état avant/après

Décrivez la situation actuelle : quels processus se déroulent comment, avec quels outils (listes Excel, papier, solutions isolées), où surviennent des erreurs, des doublons ou des temps d'attente ? Notez ce que le nouveau logiciel doit concrètement améliorer. Une distinction claire entre l'état avant et après aide le développeur à définir les bonnes priorités si le budget ou les délais viennent à être sous pression.

Si le logiciel traite des données personnelles, un inventaire des flux de données fait partie intégrante de la situation initiale. La liste de contrôle de Swisscom relative à la Loi sur la protection des données recommande une entrée en matière pragmatique : examinez les applications métier existantes à la recherche de données personnelles et notez leur origine, leur utilisation et leur lieu de stockage.

Selon cette liste de contrôle, il est ainsi possible d'obtenir une vue d'ensemble avec plus de 80 pour cent d'exhaustivité. Pour les travaux purement internes, la source indique un budget temps d'environ un jour de travail, avec un affinage ultérieur.

Étapes pour élaborer un cahier des charges pour les PME en Suisse

Clarifier les groupes d'utilisateurs et les autorisations

Listez les personnes qui utilisent le logiciel : collaborateurs, clients, partenaires, administrateurs. Pour chaque rôle, définissez ce qu'il a le droit de voir, lire, modifier et supprimer. Un magasinier ne voit pas les mêmes choses qu'un directeur général. Celui qui définit les rôles tôt économise du travail par la suite, car les concepts d'autorisation ne peuvent être modifiés a posteriori qu'en intervenant dans la logique existante.

Il convient également de clarifier : qui a le droit d'exporter des données, qui peut modifier les données de base, qui attribue les droits d'accès ? Si des tiers obtiennent un accès (portail client, accès partenaire), des questions d'authentification et de journalisation des accès s'ajoutent.

Formuler les exigences fonctionnelles sous forme de récits utilisateur vérifiables

Formulez les fonctions sous forme de récits utilisateur : « En tant que conseiller clientèle, je souhaite créer une nouvelle offre, l'envoyer au client par e-mail et suivre son statut. » Et non : « Le système doit disposer d'un module d'offres. » La différence réside dans la vérifiabilité. À la fin du projet, on peut répondre par oui ou non à la question de savoir si chaque récit utilisateur a été satisfait – le conseiller clientèle peut-il le faire ou non ?

Pour chaque récit, précisez quelles données doivent être saisies et quel résultat doit être visible. Des termes génériques comme « convivial » ou « flexible » laissent cette réponse ouverte et n'ont pas leur place dans une exigence, tout au plus dans un objectif qualité séparé.

Compléter avec les exigences non fonctionnelles et la protection des données

Les exigences de performance ne décrivent pas une fonction, mais les conditions : quelle vitesse de chargement est requise pour une page, combien d'utilisateurs simultanés doivent être pris en charge, quels navigateurs et appareils sont obligatoires ? Ces indications déterminent l'architecture et l'effort de test.

Si le logiciel traite des données personnelles, les dispositions de la Loi fédérale sur la protection des données (LPD) révisée, entrée en vigueur le 1er septembre 2023, s'appliquent. Le Préposé fédéral à la protection des données et à la transparence (PFPDT) souligne que la LPD est formulée de manière neutre sur le plan technologique et s'applique donc directement aux applications d'IA.

Trois points doivent dès lors être inclus comme exigences dans le cahier des charges : la transparence concernant la finalité, le fonctionnement et les sources de données ; un droit d'opposition des personnes concernées contre les décisions individuelles automatisées ; une analyse d'impact relative à la protection des données pour les applications à haut risque. Si le logiciel est exploité chez un hébergeur ou un fournisseur cloud, ou s'il accède à des systèmes tiers, un contrat de traitement des données fait partie des exigences.

Si des fonctions d'IA sont prévues, des règles relatives aux sorties doivent être établies : les sorties de l'IA sont des suggestions, pas des faits vérifiés. Avant tout contact avec le client, publication, effet contractuel ou réservation, une personne compétente doit contrôler l'exactitude, l'exhaustivité, le ton et les sources. Les décisions autonomes ayant des effets juridiques ou financiers doivent être exclues en tant que cas d'utilisation, et les informations sensibles telles que les mots de passe, les clés ou les dossiers clients complets ne doivent pas être saisies dans des outils externes.

Avantages et risques de l'utilisation de l'IA dans les logiciels d'entreprise (Suisse)

Décrire les interfaces avec les systèmes existants

Notez avec quels systèmes existants le nouveau logiciel doit communiquer – par exemple Bexio, Abacus, un ERP, un outil de newsletter, une boutique en ligne ou une solution sectorielle. Pour chaque interface, il faut clarifier s'il existe une API documentée ou si un échange de fichiers est nécessaire.

Pour chaque interface, quatre indications doivent figurer dans le cahier des charges : sens des données (lecture, écriture ou les deux), objets et champs de données concernés, rythme (temps réel, horaire, traitement nocturne) et gestion des erreurs. Pour la gestion des erreurs, il faut répondre à la question de savoir ce qui se passe si le système cible n'est pas accessible, si un jeu de données est rejeté ou si deux systèmes modifient simultanément le même jeu de données. Sans ces quatre indications, des efforts imprévus surviennent en plein milieu du projet.

Délimitation contre le « scope creep »

Notez aussi clairement ce qui ne fait pas partie du projet : les fonctions qui n'arriveront que dans une phase ultérieure, les systèmes qui ne seront pas connectés, les migrations de données que le mandant effectue lui-même, ainsi que l'étendue de la formation et de la documentation.

Cette délimitation est le frein le plus efficace contre les extensions rampantes. Elle rend visible lorsqu'un nouveau souhait apparaît et permet de le traiter comme un avenant avec ses propres efforts et délais, plutôt que de le payer tacitement sur le budget en cours.

Régler les conditions techniques et les questions de propriété

Prescriptions relatives à l'exploitation : le logiciel doit-il fonctionner sur un serveur spécifique ou dans une infrastructure existante ? Y a-t-il des prescriptions concernant la base de données, le langage de programmation ou les normes d'interface ? Le code source doit-il appartenir à l'entreprise ? Clarifiez également avant la signature du contrat ce qui se passe en cas de changement de prestataire – exportation des données, documentation et transfert du savoir-faire.

Si l'entreprise ou le produit a un lien avec l'UE, des échéances réglementaires s'ajoutent. Pour les systèmes d'IA à haut risque selon l'annexe III de l'EU AI Act, des prescriptions strictes s'appliquent à partir du 2 décembre 2027. À partir du 11 décembre 2027, le Cyber Resilience Act s'applique intégralement.

Les prestataires suisses peuvent être concernés, même sans établissement dans l'UE. Le critère déterminant est de savoir si les produits ou services sont spécifiquement orientés vers le marché de l'UE – par exemple via un site web adapté aux clients de l'UE, des possibilités de livraison dans les États de l'UE ou des indications de prix en euros.

Échéances réglementaires pour l'IA et la cybersécurité en Suisse (lien UE)

Déterminer le niveau de détail et les critères de réception

La règle empirique est la suivante : rédiger avec suffisamment de détails pour que deux développeurs différents comprennent la même chose. Si une phrase laisse place à l'interprétation, elle sera mal interprétée. Vérifiez donc chaque exigence en vous posant la question inverse : deux personnes décriraient-elles indépendamment la même fonction ?

En découlent les critères de réception : pour chaque exigence, on note comment la satisfaction est mesurée. Pour les récits utilisateur, il s'agit de savoir si la personne décrite peut effectuer l'action décrite. Précisez qui reçoit (service spécialisé, direction de projet, direction générale) et dans quel environnement les tests sont effectués – avec des données de test, sur un système de test et avec les interfaces réelles.

L'effort consacré aux détails doit correspondre au risque : là où des données clients, personnelles, contractuelles ou financières sont traitées ou où des décisions automatisées sont préparées, il faut plus de contrôle, de journalisation et de documentation que pour une fonction qui structure uniquement des informations publiques. Le cahier des charges n'est pas un document final : les thèmes liés à la protection des données et à la sécurité sont généralement affinés après une première passe.