Guideline 1.4.1 Physical Harm : app de santé refusée

La guideline 1.4.1 vise les apps de santé qui pourraient donner une information fausse, ou servir à diagnostiquer ou à soigner. Apple les examine de plus près. Pour passer, l'app publie ses sources et sa méthode, ne prétend mesurer que ce qu'elle mesure vraiment et rappelle de consulter un médecin. Une app qui affirme mesurer la tension avec les seuls capteurs de l'iPhone est refusée.

Ce guide parle de la revue d'Apple, pas de médecine : rien ici n'est un conseil médical. Je publie mes propres apps iOS. Plus bas, un exemple construit montre comment cadrer, face à la 1.4.1, une app d'alimentation pour bébé. Le texte officiel a été lu le 15 octobre 2026. Pour les autres motifs, lis pourquoi Apple refuse une app.

Que dit la guideline 1.4.1 ?

La 1.4, « Physical Harm », appartient à la section « Safety » des App Review Guidelines. Elle s'ouvre ainsi : « If your app behaves in a way that risks physical harm, we may reject it. » La 1.4.1 vise ensuite les apps médicales : « Medical apps that could provide inaccurate data or information, or that could be used for diagnosing or treating patients may be reviewed with greater scrutiny. »

Le texte pose quatre exigences :

• Des données et une méthode publiées. « Apps must clearly disclose data and methodology to support accuracy claims relating to health measurements ». Si la précision ou la méthode ne peut pas être validée, l'app est refusée.
• Pas de fausse mesure par capteur. Apple refuse les apps qui prétendent faire une radio, ou mesurer la tension, la température, la glycémie ou l'oxygène du sang « using only the sensors on the device ».
• Un rappel du médecin. « Apps should remind users to check with a doctor in addition to using the app and before making medical decisions. »
• Le lien vers l'autorisation. Si ton app a reçu une autorisation réglementaire, joins le lien vers ce document à ta soumission.

Les règles voisines de la section 1.4

Le refus peut aussi citer une sous-règle voisine.

Règle	Ce qu'elle vise	Ce qu'Apple attend
1.4.1	Apps médicales	Sources, méthode, médecin
1.4.2	Calcul de dose	Éditeur agréé ou autorisation
1.4.3	Tabac, drogues, alcool	Aucune incitation
1.4.4	Contrôles routiers	Sources officielles
1.4.5	Défis risqués	Aucun défi dangereux

La 1.4.2 est la plus stricte. Un calculateur de dose de médicament doit venir du fabricant, d'un hôpital, d'une université, d'une assurance santé, d'une pharmacie ou d'une autre entité agréée, ou être approuvé par la FDA ou son équivalent. Un développeur seul, sans autorisation, ne peut donc pas publier un calculateur de dose. La 1.4.3 vise aussi les apps qui poussent à boire trop, comme certains jeux à boire.

Ton app est-elle une « app médicale » ?

Apple ne donne pas de liste. Trois repères officiels aident à trancher.

Le questionnaire de classification par âge. Ses définitions séparent deux familles. « Medical or Treatment Information » couvre le diagnostic et la prise en charge d'une maladie, comme des conseils sur un médicament ou les urgences. « Health or Wellness Topics » couvre les conseils de mode de vie : suivi des calories, régime, exercices. Une app de sport qui propose des exercices relève plutôt de la seconde. Dans la grille d'Apple, le bien-être apparaît dès le palier 9+, l'information médicale occasionnelle au palier 13+, fréquente au palier 16+.

La déclaration de dispositif médical. Une app disponible dans l'Union européenne, au Royaume-Uni ou aux États‑Unis doit déclarer si elle est un dispositif médical réglementé dans deux cas. Sa catégorie principale ou secondaire est Forme et santé ou Médecine. Ou elle a répondu « fréquent » à l'information médicale du questionnaire. Sans fonction de santé, tu réponds non.

Le droit du pays. En France, l'ANSM rappelle que certains logiciels sont des dispositifs médicaux, parce qu'ils ont une finalité médicale. Ils doivent alors être marqués CE, et leur statut dépend notamment de leur destination. Si ton app diagnostique, surveille une maladie ou soigne, la question est réglementaire avant d'être une question de revue.

Sur les forums d'Apple, des développeurs rapportent des refus 1.4.1 pour des apps de sommeil, de calcul d'IMC ou de suivi alimentaire, qu'ils jugeaient de simple bien-être. Le reviewer juge ce que l'app affiche, pas la catégorie choisie.

Mesurer avec l'iPhone : la promesse compte plus que le capteur

Exemple construit : une app qui demande de poser le doigt sur la caméra, puis affiche une tension. Le téléphone seul ne permet pas de valider ce chiffre : c'est l'exemple même de la règle. La même app risque aussi la 1.1.6, qui refuse les données d'appareil inexactes.

Deux voies restent ouvertes. Soit tu lis, via HealthKit, des mesures prises par un appareil conçu pour cela, en affichant leur source. Soit tu publies la méthode et les données qui prouvent ta précision, ce qui suppose une vraie validation.

Avec HealthKit, quelques règles s'ajoutent :

• Les règles de design HealthKit disent de ne pas demander l'accès aux données de santé sans fonction de santé, et de le demander au moment où il sert.
• La règle 5.1.3 interdit d'écrire des données fausses dans HealthKit, de stocker des données de santé personnelles dans iCloud et de s'en servir pour la publicité.
• Chaque accès demande son texte d'explication dans l'Info.plist, comme la caméra : voir le guide ITMS-90683.
• La documentation HealthKit prévient qu'App Review peut refuser une app qui active les dossiers médicaux sans s'en servir.

Sources, avertissement, médecin : où les placer

Des messages de refus 1.4.1 publiés sur les forums d'Apple demandent des citations dans l'app, avec des liens vers les sources faciles à trouver. Un avertissement complète des sources sérieuses, il ne les remplace pas.

Ce que je ferais :

• Un lien « Sources » sous chaque conseil, vers l'organisme qui le donne : OMS, autorité de santé du pays, société savante.
• Le rappel du médecin là où la personne lit le conseil, pas seulement dans les conditions d'utilisation.
• La même prudence sur la fiche : aucune promesse de guérir, de diagnostiquer ou de remplacer un professionnel.

Exemple : cadrer une app d'alimentation pour bébé

Si tu prépares une app de diversification alimentaire pour bébé, voici un exemple de cadrage. Ce n'est pas une validation d'Apple. Une app d'alimentation n'est pas forcément médicale. Mais parler d'âge, d'allergènes et de risque d'étouffement à des parents se rapproche vite de la 1.4.1.

Voici comment la cadrer :

• Pas de promesse médicale. L'app aide à cuisiner et à suivre les repas. Elle ne diagnostique rien et ne remplace pas le pédiatre.
• Des sources officielles, citées dans l'app. Pars des recommandations de l'OMS sur l'alimentation complémentaire, puis de celles de chaque pays. En France, Santé publique France publie la brochure Pas à pas, votre enfant mange comme un grand.
• Une relecture humaine. Rédige le contenu à partir de ces sources, puis fais-le relire par une diététicienne ou une pédiatre avant publication. Aucun faux expert.
• Un avertissement visible : « à titre informatif », avec le rappel de demander l'avis du pédiatre.
• Les premiers secours par lien officiel, plutôt que des consignes écrites par toi.
• Les allergies traitées comme des données de santé : accord explicite, collecte minimale, export, suppression et déclaration fidèle dans App Privacy.

Tu peux choisir la catégorie Cuisine et boissons, si c'est ce que fait l'app. Mais la catégorie ne protège pas : si l'écran donne un conseil de santé, la 1.4.1 s'applique.

Check-list « app de santé ou d'alimentation » avant soumission

• L'app ne diagnostique pas, ne soigne pas, ne calcule pas de dose, ou tu as l'autorisation qui va avec.
• Chaque conseil de santé a un lien vers une source officielle, facile à trouver.
• Un écran « Sources et méthode » liste toutes les références.
• Le rappel de consulter un médecin apparaît à côté des conseils.
• Aucune mesure ne vient des seuls capteurs de l'iPhone sans méthode validée et publiée.
• Les calculs (âge, quantités, scores) sont couverts par des tests avec des cas limites.
• HealthKit n'est demandé que pour une fonction de santé, au moment utile.
• Aucune donnée de santé ne part dans iCloud, dans la publicité ou dans le texte d'une notification.
• La déclaration de dispositif médical est remplie si ta catégorie ou ton questionnaire l'exige.
• Le questionnaire de classification par âge décrit le contenu médical réel.
• Une app qui fournit un service de santé est soumise par une organisation : la règle 5.1.1(ix) le demande. Le statut se choisit à l'inscription au programme développeur.
• Les notes de revue disent où trouver les sources, l'avertissement et, s'il existe, le lien vers l'autorisation.

Répondre à un refus 1.4.1

1. Repère ce que le reviewer cite : une mesure, un conseil sans source, une fonction de diagnostic.
2. Corrige dans le build : sources visibles, rappel du médecin, fonction retirée si elle ne peut pas être validée.
3. Aligne la fiche : description, sous-titre et captures sans promesse médicale.
4. Réponds avec les emplacements, comme expliqué dans répondre à App Review.

Un modèle en anglais, à adapter, en ne gardant que ce qui est vrai :

Hello,

Thank you for your feedback regarding Guideline 1.4.1.

In build [X]:
- every health recommendation links to its source
  ([organization]); see [screen] > "Sources";
- a reminder to consult a doctor appears on [screens];
- [feature] no longer claims to measure [value].

Best regards,
[Your name]

Si l'app a une autorisation réglementaire, joins le lien vers le document. Sinon, n'en invente pas : Apple demande la preuve.

Passer la 1.4.1 dès ta prochaine soumission

Le Kit Review Apple rassemble ce que je vérifie avant chaque envoi, avec deux skills qui relisent ton projet dans Claude Code et préparent ta réponse si Apple refuse. Pour un regard humain, réserve une heure avec moi : on relit tes écrans de conseils et ta fiche ensemble. La démarche complète est sur la page application refusée par Apple.

Si tu prépares ta première sortie, fais ton diagnostic gratuit : il te dit quelle étape attaquer d'abord et t'envoie ma checklist anti-refus Apple.

Personne ne peut garantir qu'Apple acceptera ton app. Des sources visibles et des promesses mesurées retirent au moins ce motif de la liste.

Questions fréquentes

Que veut dire « Guideline 1.4.1 - Safety - Physical Harm » ?

C'est l'intitulé du refus dans le message d'Apple. Le reviewer juge qu'une information de santé de ton app pourrait être fausse, ou servir à diagnostiquer, sans les garanties attendues : sources, méthode, rappel du médecin ou autorisation.

Un avertissement suffit-il à passer la guideline 1.4.1 ?

Non. Le rappel de consulter un médecin fait partie des exigences, mais il ne remplace ni les sources ni la méthode. Une mesure impossible à valider reste refusée, même avec un avertissement en tête d'écran.

Une app peut-elle mesurer la tension avec la caméra de l'iPhone ?

Non. La 1.4.1 cite la tension, la température, la glycémie et l'oxygène du sang parmi les mesures interdites avec les seuls capteurs du téléphone. Pour toute autre mesure, il faut publier les données et la méthode qui prouvent la précision.

Faut-il une entreprise pour publier une app de santé ?

Pour un service de santé, oui : la règle 5.1.1(ix) demande que les apps des secteurs très réglementés, dont la santé, soient soumises par l'entité qui fournit le service. Une app de recettes ou de bien-être n'est pas forcément un service de santé.

Quelle classification par âge pour une app de santé ?

Elle dépend de tes réponses au questionnaire. Dans la grille d'Apple, des sujets de bien-être apparaissent dès le palier 9+, une information médicale occasionnelle au palier 13+ et fréquente au palier 16+. Réponds selon le contenu réel, pas selon le palier visé.