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

> Guideline 1.4.1 : une app de santé cite ses sources, prouve ses mesures et rappelle de consulter un médecin. Check-list avant soumission, exemple d'app bébé.

Page originale : [Guideline 1.4.1 Physical Harm : app de santé refusée](https://devoria.fr/blog/guideline-1-4-1-sante-securite)
Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi)
Publication : 2026-11-04
Dernière révision du contenu : 2026-11-04


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](https://devoria.fr/blog/pourquoi-apple-refuse-votre-app).

## Que dit la guideline 1.4.1 ?

La 1.4, « Physical Harm », appartient à la section « Safety » des [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#1.4.1). 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](https://developer.apple.com/help/app-store-connect/reference/app-information/age-ratings-values-and-definitions) 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é](https://developer.apple.com/help/app-store-connect/manage-app-information/declare-regulated-medical-device-status) 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](https://ansm.sante.fr/documents/reference/logiciels-et-applications-mobiles-en-sante) 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](https://developer.apple.com/design/human-interface-guidelines/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](https://developer.apple.com/app-store/review/guidelines/#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](https://devoria.fr/blog/itms-90683-missing-purpose-string-expo).
- La [documentation HealthKit](https://developer.apple.com/documentation/healthkit/setting-up-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](https://developer.apple.com/forums/thread/703502) 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](https://www.who.int/health-topics/complementary-feeding), puis de celles de chaque pays. En France, Santé publique France publie la brochure [Pas à pas, votre enfant mange comme un grand](https://www.santepubliquefrance.fr/nutrition-et-activite-physique/brochure/pas-a-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](https://devoria.fr/blog/app-privacy-app-store-connect).

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](https://devoria.fr/blog/guideline-4-5-4-notifications-push).
- 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](https://devoria.fr/blog/compte-developpeur-apple-prix-inscription).
- 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](https://devoria.fr/blog/repondre-app-review-resolution-center).

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

```text
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](https://devoria.fr/kits/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](https://devoria.fr/coaching) : on relit tes écrans de conseils et ta fiche ensemble. La démarche complète est sur la page [application refusée par Apple](https://devoria.fr/expertise/application-refusee-par-apple).

Si tu prépares ta première sortie, [fais ton diagnostic gratuit](https://devoria.fr/diagnostic) : 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é.


## Ton projet

[Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement.

[Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement.

[Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio.

[Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.