Guide

Logiciel sur mesure et protection des données : ce qu'exige le RGPD

Dès qu'un logiciel sur mesure traite des données à caractère personnel, des obligations claires s'appliquent. Quelles sont-elles concrètement, ce qui manque presque toujours en pratique et ce qui suffit réellement.

Demander une évaluation ↗Logiciel sur mesure

Offre sur demandeà partir de 8 semaines jusqu'à la première versionÉtat 2026

En bref

Dès qu'un logiciel sur mesure traite des données à caractère personnel, il faut une base juridique, une limitation de finalité, des délais de suppression définis, une information des personnes concernées et un contrat de sous-traitance avec chaque prestataire impliqué. En pratique, ce sont presque toujours les trois mêmes points qui manquent : le délai de suppression, la mention au point de collecte et la clarification de savoir si le prestataire utilise les données pour sa propre formation.

01 — Protection des données

Ce qu'exige le RGPD

Dès que des données à caractère personnel sont traitées — et cela arrive plus vite qu'on ne le pense, par exemple dès que quelqu'un saisit un nom ou un numéro de téléphone — les obligations habituelles s'appliquent : indiquer la base juridique, définir la finalité, respecter la minimisation des données, définir les délais de suppression, informer les personnes concernées.

Concrètement, cela signifie pour un logiciel sur mesure : un contrat de sous-traitance avec chaque prestataire impliqué, la vérification de l'endroit où les données sont traitées, un délai de suppression documenté et un passage compréhensible dans la déclaration de confidentialité. Trois choses manquent presque toujours en pratique : le délai de suppression défini, la mention à l'endroit où les données sont collectées, et la clarification de savoir si le prestataire utilise les données pour sa propre formation.

Une analyse d'impact relative à la protection des données n'est nécessaire qu'en cas de risque élevé probable — ce qui n'est pas le cas pour la plupart des projets de ce type. L'examen lui-même devrait néanmoins être documenté, afin qu'il soit possible de justifier a posteriori pourquoi il a été écarté.

02 — Contrat

Ce qui doit être clarifié par écrit

Propriété des données et des accès. Ils appartiennent au donneur d'ordre. Si un fournisseur ne le confirme pas clairement, c'est l'information la plus importante de l'entretien.
Restitution en cas de résiliation. Dans quel format, dans quel délai, à quel coût.
Pas de durée minimale sans contrepartie. Un engagement est acceptable s'il y a quelque chose en retour — sinon non.
Ce que coûte une modification ultérieure. Ce n'est pas le prix du projet qui détermine les coûts globaux, mais le taux horaire de la troisième année.
La documentation comme élément livrable. Pas comme promesse, mais comme poste dans l'offre.

03 — Risques

Ce qui peut mal tourner

Le système répond faux. Limitez cela en le faisant travailler exclusivement à partir de contenus vérifiés et en le configurant pour qu'il transfère en cas d'incertitude au lieu de deviner. C'est une décision de configuration, pas une propriété de la technologie.
L'effort est sous-estimé. Raison la plus fréquente : situation de départ floue. Un état des lieux honnête avant l'offre l'évite plus sûrement que n'importe quelle marge de sécurité.
Personne ne le maintient. Le plus grand risque de tous — et le plus facile à éviter.
Failles dans la protection des données. Elles proviennent presque toujours de délais de suppression manquants et de responsabilités floues, rarement de la technologie elle-même.
Dépendance vis-à-vis du fournisseur. Évitable si les accès, données et documentation appartiennent contractuellement au donneur d'ordre.

04 — Questions

Questions fréquentes

Comment éviter que le projet ne déraille ?

Petites étapes avec résultat utilisable, budgets fixes par étape, et possibilité de sortir après chaque étape. Les grands projets à prix fixe sur douze mois sont le moyen le plus fiable d'aboutir à la déception — des deux côtés.

Pouvons-nous commencer par un tableur ?

Souvent oui, et c'est un bon test. Si le tableur reflète le processus et échoue uniquement sur le multi-utilisateur, les droits ou le volume de données, l'exigence est claire et le projet chiffrable.

À qui appartient le code source ?

À vous, intégralement, dès le paiement. C'est dans le contrat. Vous pouvez aller avec vers n'importe quel autre développeur — c'est le principe.

Que se passe-t-il si nous découvrons de nouvelles exigences pendant le développement ?

C'est normal et prévu, car le travail se fait par petites étapes. Une nouvelle exigence est intégrée à l'étape suivante, au lieu de bloquer tout le projet.

Combien d'utilisateurs un tel système supporte-t-il ?

Cela dépend de l'architecture que nous planifions selon votre croissance attendue — de quelques utilisateurs dans l'entreprise propre jusqu'à plusieurs centaines sur plusieurs sites.

Quand un logiciel propre se justifie-t-il face à un logiciel standard ?

Lorsque votre processus est un véritable avantage concurrentiel, lorsque le logiciel standard ne correspond qu'à soixante-dix pour cent et que le reste finit en travail manuel, ou lorsque les coûts de licence par utilisateur dépassent le développement sur quelques années. S'il s'agit seulement de confort, le logiciel standard est meilleur marché.

Cela fonctionne-t-il sur nos propres serveurs ou dans le cloud ?

Les deux sont possibles. Pour la plupart des entreprises, une solution cloud nécessite moins de maintenance ; là où les données ne doivent pas quitter les locaux, nous l'installons sur l'infrastructure propre.

05 — Suite

Pages correspondantes

Logiciel sur mesure par région

Prochaine étape

Envoyez-nous quelques phrases sur votre projet.

Nous lisons chaque demande nous-mêmes et vous répondons personnellement. Pas d'équipe commerciale, pas de formulaire de rappel dans le vide.

Envoyer une demande ↗ office@pipeline-solutions.at OU +43 681 207 64 203