La digitalisation des services à la personne progresse rapidement : entre gestion des plannings, facturation et aides à la décision, de nombreux logiciels intègrent des modules d’intelligence artificielle. Face à ce mouvement, choisir un logiciel de gestion conforme à l’AI Act devient un impératif pour les structures (TPE/PME, associations et prestataires) qui veulent réduire leurs risques juridiques et protéger les personnes fragiles (personnes âgées, handicapées, mineurs).
Cet article synthétise les obligations clés du Règlement (AI Act) (n°2024/1689) et propose une checklist opérationnelle pour sélectionner un éditeur. Il reprend les échéances légales, les critères de « haut risque », les exigences techniques (documentation Annexe IV, logs automatisés, gestion des risques) et les points contractuels indispensables (DPA, représentation UE, SLA d’incident).
Pourquoi l’AI Act change la donne pour les services à la personne
L’AI Act vise « to foster responsible artificial intelligence development and deployment in the EU. » Ce cadre réglementaire européen impose des obligations spécifiques aux systèmes d’IA dits « à haut risque » qui peuvent s’appliquer aux logiciels de gestion des services à la personne lorsqu’ils influencent des décisions sur la santé, la sécurité ou les droits fondamentaux (Art.6, Recital 52).
Pour les acteurs du secteur, cela signifie que des fonctions d’automatisation (scoring, priorisation d’interventions, allocation d’aides) peuvent transformer un logiciel standard en SIA à haut risque. Les conséquences vont au-delà de la conformité technique : gouvernance, documentation, supervision humaine et contrats doivent être revus pour répartir clairement les responsabilités (Arts.16‑26).
En pratique, l’adoption d’une solution conforme doit concilier obligations AI Act et RGPD : le Règlement IA complète le RGPD sans le remplacer, notamment sur les traitements de données personnelles employés par l’IA (bases légales, AIPD/DPIA, droits des personnes). La CNIL rappelle l’importance du privacy by design et des AIPD pour tout projet IA impliquant des données sensibles.
Dates clés, calendrier et périmètre d’application
Le Règlement (AI Act) (n°2024/1689) a été publié le 12/07/2024 et « entre en vigueur vingt jours après publication ». Le calendrier détaillé figurant à l’article 113 précise des dates d’application différenciées : certaines dispositions (Chapitres I & II) sont applicables dès le 2 février 2025, plusieurs obligations (fournisseurs de modèles à usage général, gouvernance, sanctions) prennent effet le 2 août 2025 et le Règlement s’applique globalement à partir du 2 août 2026.
Les États membres doivent par ailleurs mettre en place au moins une sandbox nationale opérationnelle avant le 2/08/2026, et la gouvernance européenne (AI Office + European AI Board) publiant codes de bonnes pratiques et templates facilitera la mise en conformité.
Enfin, notez l’obligation d’enregistrement des SIA figurant en Annexe III dans un registre EU (Art.71/49) : les fournisseurs/déployeurs de systèmes à finalité marché devront fournir métadonnées, documentation et contacts pour inscription.
Quand votre logiciel devient‑il « haut risque » et quels en sont les impacts ?
Un SIA est classé « haut‑risque » s’il figure en Annexe III ou s’il influence matériellement des décisions ayant un impact significatif sur la santé, la sécurité ou les droits fondamentaux (Art.6, Recital 52). Pour les services à la personne, l’automatisation de l’attribution de soins, la priorisation d’interventions, le scoring des besoins ou le profilage de personnes fragiles augmentent considérablement le profil de risque.
Lorsque le logiciel est qualifié de haut risque, s’appliquent des exigences strictes : système de gestion des risques, gouvernance, qualité des données, documentation technique complète (Annexe IV), journalisation automatique, supervision humaine, robustesse et cybersécurité, surveillance post‑commercialisation et évaluations de conformité avant mise sur le marché (Ch. III, Section 2, Arts.8, 19).
La qualification haut‑risque a aussi des conséquences contractuelles et opérationnelles : il faudra inscrire le système au registre EU, prévoir une documentation accessible aux autorités, et mettre en place des plans d’intervention et de monitoring post‑market ainsi que des procédures de signalement d’incidents (Art.73).
Exigences techniques et documentation obligatoire
La documentation technique d’un SIA à haut risque doit être rédigée avant la mise sur le marché, tenue à jour et contenir au minimum les éléments listés en Annexe IV (description, version, données d’entraînement/validation, protocoles de test, système de gestion des risques, plan de surveillance post‑commercialisation, etc.) (Art.11 & Annexe IV). Cette documentation doit être disponible pour les autorités et, en cas de demande, fournie dans des délais compatibles avec les contrôles réglementaires.
La traçabilité est centrale : les SIA à haut risque doivent permettre l’enregistrement automatisé d’événements pertinents (entrées/sorties, version du modèle, paramètres, durée d’utilisation, interventions humaines) pour audits et surveillance post‑commercialisation (Art.12/Art.19 & Annexes). Les exigences de conservation et d’accès aux logs sont strictes et doivent être contractualisées (durée, accès, exportabilité).
La gestion des risques est continue et itérative : identification/estimation des risques, tests, mesures d’atténuation, prise en compte des groupes vulnérables et essais en conditions réelles si pertinent (Art.9). Les fournisseurs doivent aussi documenter les tests de robustesse et non‑biais (audits tiers, adversarial testing, non‑régression) et, si possible, détenir des certifications (ISO 27001, SOC2).
Contrats, gouvernance et responsabilités dans la chaîne de valeur
L’AI Act distingue clairement les rôles : fournisseurs (providers), déployeurs (deployers), importateurs/distributeurs et représentants UE. La responsabilité se répartit selon ces rôles ; un déployeur qui modifie substantiellement le système peut devenir responsable (Arts.16‑26). Il est donc essentiel de clarifier ces statuts dans le contrat commercial.
Au plan contractuel, exigez un Data Processing Agreement (DPA) précisant finalités, sous‑traitance, lieu d’hébergement, durée de conservation des logs, SLA pour accès aux logs et assistance en cas d’incident. Pour éditeurs hors UE, le texte impose la nomination d’un représentant autorisé dans l’UE (Art.22).
La CNIL encourage les acteurs à concilier innovation et protection des données : « concilier le développement de systèmes d’IA avec les enjeux de protection de la vie privée ». Profitez des fiches pratiques, bacs à sable sectoriels et dispositifs d’accompagnement renforcé pour PME proposés par la CNIL afin d’articuler RGPD et AI Act.
Gestion des incidents et sanctions : que prévoir ?
Les fournisseurs de SIA à haut risque doivent déclarer tout « serious incident » aux autorités nationales ; les délais standards sont « dès causalité établie et au plus tard 15 jours », avec des délais plus courts selon la gravité : décès ≤ 10 jours ; incidents généralisés ou à fort impact ≤ 2 jours. Un rapport initial incomplet peut être suivi d’un rapport complet (Art.73).
Les sanctions prévues sont sévères et destinées à être dissuasives : les États membres doivent mettre en place des règles de sanction, le texte fixe des plafonds européens (pratiques interdites = jusqu’à 35 M€ ou 7% du chiffre d’affaires mondial ; non‑conformité aux obligations d’opérateurs = jusqu’à 15 M€ ou 3% du CA mondial ; information incorrecte aux autorités = jusqu’à 7,5 M€ ou 1% du CA), appliquant « whichever is higher » (Art.99).
Au‑delà des amendes, la non‑conformité peut entraîner la suspension ou le retrait du marché d’un SIA, des obligations de remédiation et un fort impact réputationnel : il est donc stratégique d’intégrer la conformité dès la sélection et la contractualisation du logiciel.
Checklist technique et questions à poser avant l’achat
Voici les éléments techniques minimaux à exiger d’un éditeur : architecture de logs automatiques exportables et non‑altérables ; versioning et export des modèles/paramètres ; documentation Annexe IV tenue à jour ; capacité d’interruption / override humain et enregistrement des interventions ; plan de post‑market monitoring et incident response ; chiffrement des données au repos/en transit ; hébergement et traitements sur infrastructure EU si possible ; DPA et représentant UE pour éditeurs hors UE (Arts.11,12,14,15,72).
Questions concrètes à poser (format prêt à l’emploi) : le logiciel contient‑il des modèles ML/IA ? fournissez‑vous la documentation Annexe IV ? quels logs sont produits et pendant combien de temps sont‑ils conservés ? où sont hébergées les données ? avez‑vous un processus de FRIA / AIPD ? pouvez‑vous démontrer tests de robustesse et non‑biais ? avez‑vous assurance / plans d’intervention en cas d’incident ? nommez‑vous un représentant UE si hors UE ?
Pour les PME/TPE, l’AI Act prévoit des allègements (documentation technique simplifiée, formulaires simplifiés) mais pas d’exemption totale. Utilisez les sandboxes nationales, les codes de bonne pratique et l’accompagnement CNIL pour alléger la charge administrative tout en respectant les exigences.
Bonnes pratiques et certifications recherchées chez les éditeurs
Recherchez des preuves de management de la sécurité (ISO 27001), des processus de développement sécurisé, des audits tiers (SOC2), des tests d’adversarial robustness et de non‑régression, ainsi que des « model cards » ou fiches techniques détaillant la provenance des données d’entraînement. Ces éléments facilitent les évaluations de conformité et les audits réglementaires (Article 15, recommandations ENISA/BSI).
Demandez des attestations sur l’absence de fonctions interdites (par ex. « scoring social ») et sur les mesures de mitigation pour les groupes vulnérables. Assurez‑vous que le fournisseur dispose d’un plan de surveillance post‑commercialisation et d’indicateurs de performance/clés pour le suivi continu.
Enfin, contractualisez des SLA clairs pour l’accès aux logs, la coopération avec les autorités, la fourniture de documentation sur demande et les délais d’intervention en cas d’incident. Ces engagements sont essentiels pour limiter l’exposition réglementaire et répondre aux obligations d’audit.
Ressources, outils et accompagnement disponibles
La Commission, l’AI Office et les autorités nationales publient guides, templates et outils d’auto‑évaluation (ex. template FRIA, modèles de post‑market monitoring). La CNIL met à disposition fiches pratiques RGPD‑IA, bacs à sable sectoriels et dispositifs d’accompagnement renforcé pour PME afin d’aider à l’articulation RGPD / AI Act.
Pour les acteurs des services à la personne, ces ressources sont précieuses : utilisez les templates FRIA, la checklist technique proposée plus haut et les sandboxes pour tester les solutions dans un cadre sécurisé et conforme avant déploiement à large échelle.
Statistiquement, la France voit une adoption élevée de logiciels de gestion par les TPE/PME (Baromètre France Num 2024 : 67% utilisent un logiciel de facturation, 65% pour la comptabilité), ce qui rend cruciale l’intégration de la conformité AI/RGPD dès le choix des solutions pour éviter des coûts de remédiation ultérieurs.
Si vous le souhaitez, je peux convertir la checklist et les questions ci‑dessus en un fichier Excel ou en modèle contractuel prêt à l’emploi pour appels d’offres ou audits internes.
En conclusion, le choix d’un logiciel de gestion pour les services à la personne doit intégrer une évaluation de risque précise (déterminer si le SIA est « haut risque »), la vérification de la documentation technique (Annexe IV), des garanties de traçabilité et d’override humain, ainsi que des clauses contractuelles strictes (DPA, représentation UE, SLA d’incident).
Agissez tôt : mettez en place une FRIA/AIPD si nécessaire, exigez preuves et certifications auprès des éditeurs, et profitez des sandboxes et outils publiés par l’AI Office et la CNIL pour sécuriser vos projets. La conformité n’est pas seulement une contrainte réglementaire : c’est un gage de confiance pour les personnes accompagnées et un levier de pérennité pour votre structure.
