Formater des données de survie dans R : objet Surv(), censure et validation
Transformez un tableur clinique désordonné en un jeu de données de survie prêt à analyser — construisez l’objet Surv(time, status), codez correctement la censure à droite/à gauche/par intervalle, mettez en place la disposition du processus de comptage (start, stop, event) et validez les données avant de modéliser
Préparez vos données pour l’analyse de survie dans R. Construisez l’objet Surv(time, status), comprenez le contrat (time, status) et le codage du statut (0/1 vs 1/2 — et le piège), gérez les trois types de censure (à droite, à gauche et par intervalle), structurez les données dépendantes du temps dans la disposition du processus de comptage (start, stop, event), et exécutez des vérifications en base R pour repérer les temps impossibles, les statuts manquants, les ID dupliqués et les ex æquo avant d’ajuster le moindre modèle.
Date de publication
26 juin 2026
Modifié
7 juillet 2026
AstucePoints clés
La réponse en analyse de survie est une paire : un temps de suivi et un indicateur de statut précisant si l’événement s’est produit ou si l’observation a été censurée. Vous regroupez la paire avec Surv(time, status) — le membre de gauche de toute formule de survie.
Surv() accepte deux codages du statut — 0 = censuré / 1 = événement, ou1 = censuré / 2 = événement. Il devine d’après les valeurs ; un + affiché après un temps signifie que ce patient est censuré. Coder le statut à l’envers est le bug de données de survie le plus courant.
Trois types de censure :à droite (la valeur par défaut — toujours sans événement au dernier contact), à gauche (type = "left" — l’événement s’est déjà produit avant la première observation) et par intervalle (type = "interval2" — l’événement est survenu entre deux visites d’évaluation).
Les covariables dépendantes du temps et les événements récurrents nécessitent la disposition du processus de comptage : découpez chaque sujet en intervalles (start, stop, event) et utilisez Surv(start, stop, event).
Validez avant de modéliser. Repérez les temps nuls/négatifs, les statuts manquants, un statut qui n’est pas un code événement/censure propre, les ID dupliqués et les ex æquo avec une poignée de vérifications en base R — une mauvaise ligne corrompt silencieusement chaque courbe et chaque hazard ratio en aval.
Introduction
Un coordinateur d’essai vous tend un tableur : une ligne par patient, une colonne de dates, une colonne « décédé/vivant », quelques cases vides, et deux ou trois lignes qui semblent dupliquées. Avant de pouvoir estimer une seule courbe de Kaplan-Meier ou ajuster un modèle de Cox, ce tableur doit devenir un jeu de données de survie prêt à analyser — et les données de survie ont une structure qui fait trébucher, car le résultat n’est pas un seul nombre mais deux : combien de temps vous avez observé chaque sujet, et si vous avez vu l’événement ou si le temps vous a manqué.
Cette leçon est l’étape de préparation des données que tout le monde saute puis regrette. Vous allez construire l’objet Surv() que chaque fonction de survie attend, coder correctement le statut (le piège 0/1 vs 1/2), gérer les trois types de censure, structurer les données dépendantes du temps dans la disposition du processus de comptage, et exécuter une courte passe de validation qui attrape les erreurs biaisant silencieusement vos résultats. Nous utilisons les jeux de données lung et colon du package survival pour que chaque exemple soit reproductible, et nous construisons de petits exemples désordonnés en base R lorsqu’il faut montrer un problème.
(La définition des critères d’évaluation — survie globale, survie sans progression — et la construction de jeux de données réglementaires CDISC ADTTE est un sujet clinique distinct ; voir Données de survie pour les soumissions réglementaires (CDISC ADTTE). Ici, nous nous concentrons sur la mécanique R qui s’applique à tout jeu de données de survie.)
Le contrat (time, status)
Chaque observation de survie porte deux informations :
time — combien de temps le sujet a été observé : de l’entrée dans l’étude jusqu’à l’événement, ou jusqu’au dernier moment où vous saviez qu’il était sans événement.
status — ce qui s’est passé à la fin de ce temps : l’événement est survenu, ou l’observation a été censurée (le temps n’est qu’une borne inférieure — le temps de l’événement réel est plus long, ou inconnu).
On ne peut pas analyser le temps seul. Un temps de suivi de 200 jours signifie quelque chose de complètement différent pour un patient qui est décédé au jour 200 que pour un patient qui était toujours vivant au jour 200 et qui a ensuite quitté l’étude. L’indicateur status est ce qui dit aux méthodes de survie de traiter le second patient comme « a survécu au moins 200 jours » plutôt que « est décédé à 200 jours » — c’est toute la raison pour laquelle la régression ordinaire échoue sur ces données.
Voici à quoi cela ressemble pour six patients, tracé sous forme de chronologie de suivi — le modèle mental derrière chaque jeu de données de survie :
# A small illustrative cohort: time = follow-up length, status = 1 event / 0 censoredpt <-data.frame(id =1:6,time =c(5, 9, 3, 11, 7, 12),status =c(1, 0, 1, 0, 1, 0) # 1 = event (death), 0 = censored (event-free at last contact))plot(NA, xlim =c(0, 13), ylim =c(0.5, 6.5),xlab ="Follow-up time (months)", ylab ="Patient", yaxt ="n",main ="Who had the event, who was censored")axis(2, at =1:6, labels =paste("P", 1:6))abline(v =12, lty =2, col ="grey60") # data cutofftext(12, 6.4, "data cutoff", pos =2, col ="grey40", cex =0.8)for (i in1:6) {segments(0, pt$id[i], pt$time[i], pt$id[i], col ="#3a86d4", lwd =3)if (pt$status[i] ==1) {points(pt$time[i], pt$id[i], pch =19, col ="#d1495b", cex =1.6) # event } else {points(pt$time[i], pt$id[i], pch =">", col ="#3a86d4", cex =1.6) # censored }}legend("bottomright", bty ="n",legend =c("event (death)", "censored (event-free)"),pch =c(19, 62), col =c("#d1495b", "#3a86d4"))
Les points rouges sont les événements ; les flèches bleues sont les patients censurés — ils étaient sans événement la dernière fois que vous les avez vus, donc leur temps de survie réel est au moins aussi long. L’analyse de survie existe pour utiliser correctement les deux types de patients. Encodons maintenant cette paire dans R.
L’objet Surv()
Surv() regroupe time et status dans l’unique objet de réponse que chaque fonction de survie lit. Utilisez le jeu de données lung (228 patients atteints d’un cancer du poumon avancé, livré avec survival — référencez-le directement, sans appel à data()) :
library(survival)# In lung: time = follow-up days; status = 1 censored, 2 = deadhead(Surv(lung$time, lung$status))
[1] 306 455 1010+ 210 883 1022+
Lisez la sortie : 306 et 455 sont des décès ; 1010+ porte un +, marquant un patient censuré — vivant à 1010 jours, donc tout ce que nous savons est que sa survie dépasse 1010 jours. Ce + est le signal affiché de la censure, et c’est la première chose à vérifier lorsque vous construisez un objet Surv() : les patients censurés ont-ils le signe plus ? Si tout le monde, ou personne, l’a, votre codage du statut est faux.
Codage du statut : 0/1 ou 1/2 (le piège)
Surv() accepte deux conventions pour status, et il infère laquelle vous avez utilisée à partir des valeurs présentes :
0 = censuré, 1 = événement — la convention la plus courante (et ce que la plupart des autres packages attendent).
1 = censuré, 2 = événement — la convention que le jeu de données lung utilise.
Une valeur logiqueTRUE/FALSE (événement/censuré) fonctionne aussi.
Les deux produisent un objet Surv identique — ce qui compte, c’est que le code le plus grand soit l’événement :
library(survival)# Same four patients, two equivalent codingsSurv(c(5, 8, 12, 3), c(1, 0, 1, 0)) # 0 = censored, 1 = event
Les deux affichent 5 8+ 12 3+ — les patients 2 et 4 sont censurés dans les deux cas. Le piège : si vos données utilisent 1 = décédé, 0 = vivant mais que vous croyez que c’est 1 = censuré, 2 = événement, ou si vous fournissez une colonne mêlant 0/1/2, Surv() peut lire silencieusement l’indicateur d’événement à l’envers. Alors chaque patient censuré est traité comme un événement et inversement — la courbe de survie, la médiane et les hazard ratios s’inversent tous, sans aucun message d’erreur. Confirmez toujours avec un rapide tableau croisé que le code que vous appelez « événement » est bien le décès/la rechute :
library(survival)# Confirm the coding before you trust it: how many events vs censored?table(status = lung$status) # 1 = censored (63), 2 = dead (165) in lung
status
1 2
63 165
165 décès et 63 censurés — cela correspond à ce que nous attendons de cette cohorte, donc le codage 1/2 est correct. Si une colonne était libellée dead avec 1 = décédé, vous recoderiez l’événement vers la valeur la plus grande (ou passeriez event =) pour que Surv() la lise correctement.
La censure à droite est la valeur par défaut
Les appels à Surv() ci-dessus utilisent tous la censure à droite — le cas de loin le plus courant, où l’événement ne s’est pas encore produit au dernier contact (le sujet est toujours sans événement, perdu de vue, ou l’étude s’est terminée). Le temps est une borne inférieure du temps de l’événement réel. Comme c’est la valeur par défaut, vous ne passez pas d’argument type ; Surv(time, status)est une donnée de survie censurée à droite.
Les deux sections suivantes couvrent les deux types de censure moins courants — n’y recourez que lorsque vos données ont effectivement cette structure.
Censure à gauche et par intervalle
Censure à gauche
La censure à gauche signifie que l’événement s’était déjà produit avant que vous observiez le sujet pour la première fois — le temps de l’événement réel est une borne supérieure. Exemple classique : lors de la première visite clinique d’un patient, un biomarqueur est déjà élevé, donc le changement s’est produit à un moment inconnu avant cette visite. Passez type = "left" :
Un - après le temps (par exemple 8-) marque l’observation censurée à gauche — l’événement s’est produit au plus tard à ce moment.
Censure par intervalle
La censure par intervalle est le cas réaliste pour les études comportant des visites d’évaluation programmées : vous savez que l’événement s’est produit entre deux visites mais pas exactement quand. Une tumeur est absente au scanner du mois 6 et présente au scanner du mois 9 — la progression est survenue quelque part dans (6, 9]. Encodez-la avec type = "interval2", en donnant un temps inférieur et un temps supérieur par sujet ; NA d’un côté signifie une borne ouverte :
library(survival)# lower = last time known event-free; upper = first time known event had occurredlower <-c(2, 4, NA, 6) # NA lower = left-censored (event before `upper`)upper <-c(NA, 5, 3, 8) # NA upper = right-censored (still event-free after `lower`)Surv(lower, upper, type ="interval2")
[1] 2+ [4, 5] 3- [6, 8]
Lisez l’affichage : 2+ est censuré à droite (sans événement au-delà de 2, borne supérieure inconnue), [4, 5] est censuré par intervalle (événement dans cette fenêtre), 3- est censuré à gauche (événement avant le temps 3), et [6, 8] est un autre intervalle. interval2 est le seul format qui exprime tous les types de censure à la fois, ce qui en fait le choix pratique lorsque les données fondées sur les visites sont mélangées. Les données censurées par intervalle nécessitent des méthodes qui respectent l’intervalle (par exemple survfit avec l’estimateur de Turnbull, ou des modèles paramétriques) — un Kaplan-Meier standard, qui suppose des temps exacts ou censurés à droite, n’est pas approprié.
La disposition du processus de comptage : (start, stop, event)
Tout ce qui précède comporte une ligne par sujet. Deux situations brisent cela : une covariable dont la valeur change pendant le suivi (une covariable dépendante du temps) et les événements récurrents (un patient qui peut connaître l’événement plus d’une fois). Les deux nécessitent la disposition du processus de comptage — découpez chaque sujet en intervalles de temps consécutifs, une ligne par intervalle, avec trois colonnes :
start — quand l’intervalle s’ouvre (le sujet devient à risque pour cette ligne) ;
stop — quand il se ferme ;
event — si l’événement s’est produit à stop (1) ou si l’intervalle s’est terminé sans événement (0).
Vous construisez la réponse Surv avec Surv(start, stop, event). Voici un patient découpé en deux intervalles — disons un traitement qui s’enclenche au temps 7 :
library(survival)# One patient, two intervals: event-free (0,7], then the event at 15# Counting-process form is Surv(start, stop, event) — the first two args are the interval endsSurv(c(0, 7), c(7, 15), c(0, 1))
[1] (0, 7+] (7,15]
L’affichage (0, 7+] puis (7, 15] montre les intervalles semi-ouverts : le premier se termine censuré (le patient était toujours sans événement à 7, où la covariable a changé), le second se termine par l’événement à 15. Les intervalles d’un même sujet doivent être contigus et non chevauchants (chaque start est égal au stop précédent).
Le jeu de données colon est un véritable exemple de type processus de comptage — chaque patient a jusqu’à deux lignes, une pour la récurrence et une pour le décès :
library(survival)# colon has multiple rows per patient id (recurrence + death)head(colon[, c("id", "time", "status", "etype", "rx")], 4)
id time status etype rx
1 1 1521 1 2 Lev+5FU
2 1 968 1 1 Lev+5FU
3 2 3087 0 2 Lev+5FU
4 2 3087 0 1 Lev+5FU
Le patient 1 apparaît sur deux lignes (etype différent), le patient 2 sur deux autres. Les données de processus de comptage sont la structure générale dont toutes les autres sont des cas particuliers — une ligne à intervalle unique (0, time, status)est le cas ordinaire censuré à droite. Construire ces intervalles à la main est source d’erreurs ; la fonction tmerge() du package survival l’automatise, traitée dans covariables dépendantes du temps.
Valider avant de modéliser
Les méthodes de survie vous donnent une courbe et une p-value à partir de n’importe quelle entrée numérique — elles ne savent pas qu’un time de -5 est impossible ou qu’un statut de 3 n’a aucun sens. Une seule mauvaise ligne corrompt silencieusement tout ce qui suit en aval. Exécutez ces vérifications en base R avant le premier survfit(). Construisez un tableau délibérément désordonné pour voir chaque vérification se déclencher :
# A messy clinical extract — every row has a different problemdat <-data.frame(id =c(101, 102, 102, 103, 104, 105),time =c(120, -5, 0, 340, 88, 200),status =c( 1, 1, 1, 3, NA, 0))dat
id time status
1 101 120 1
2 102 -5 1
3 102 0 1
4 103 340 3
5 104 88 NA
6 105 200 0
1. Temps impossibles — nuls ou négatifs. Le temps de suivi doit être positif. Un temps de 0 ou négatif est une erreur d’arithmétique sur les dates (événement avant l’entrée, dates inversées) et la plupart des fonctions l’écarteront ou bloqueront dessus :
# Flag any non-positive follow-up timedat[which(dat$time <=0), ]
id time status
2 102 -5 1
3 102 0 1
Les lignes du patient 102 ont time = -5 et time = 0 — toutes deux impossibles. Corrigez les dates à la source ; ne supprimez jamais simplement les lignes sans comprendre pourquoi.
2. Un statut qui n’est pas un code événement/censure propre. La colonne de statut ne devrait contenir que vos deux codes (0/1 ou 1/2). Tout le reste — un 3 égaré, une faute de frappe — signale un résultat mal codé :
# Which status values appear? Anything outside {0,1} (or {1,2}) is suspecttable(dat$status, useNA ="ifany")
0 1 3 <NA>
1 3 1 1
Une valeur de 3 et un NA apparaissent — un résultat manquant et un code hors plage, qui doivent tous deux être résolus (un statut NA ne peut pas être analysé ; un code hors plage est une erreur de données).
3. ID dupliqués. Dans des données à une ligne par sujet, un id répété signifie un doublon accidentel (il n’est attendu que dans des données de processus de comptage/événements récurrents, où vous valideriez différemment) :
# IDs appearing more than oncedat$id[duplicated(dat$id)]
[1] 102
Le patient 102 est dupliqué. Décidez s’il s’agit d’un véritable second intervalle (processus de comptage) ou d’une copie erronée à supprimer.
4. Ex æquo. Les ex æquo — plusieurs événements exactement au même temps — ne sont pas une erreur, mais ils affectent quelles méthodes/options vous devriez utiliser (par exemple la gestion des ex æquo du modèle de Cox, ties = "efron"). Sachez combien vous en avez :
library(survival)# Count event times shared by more than one death in the real lung dataevent_times <- lung$time[lung$status ==2]sum(table(event_times) >1) # number of time points with tied deaths
[1] 24
Les données lung ont de nombreux temps de décès ex æquo — normal pour un suivi à la résolution journalière, et la raison pour laquelle le modèle de Cox applique par défaut une correction des ex æquo.
La liste de contrôle avant de modéliser
NoteCinq vérifications avant le premier survfit()
Les temps sont positifs — pas de suivi nul ou négatif (time <= 0).
Le statut est un code propre — uniquement vos deux valeurs ; pas de valeurs égarées, pas de NA (table(status)).
Le codage de l’événement est dans le bon sens — le code le plus grand est l’événement ; l’affichage de Surv() montre + sur les patients censurés, pas sur les événements.
Une ligne par sujet (sauf s’il s’agit de données de processus de comptage) — pas d’ID dupliqués accidentels.
Le type de censure correspond aux données — à droite par défaut ; type = "left"/"interval2" uniquement lorsque la structure est réellement censurée à gauche/par intervalle.
Essayez en direct
Construisez vous-même un objet Surv() et exécutez les vérifications de validation — changez le codage du statut, ou cassez un temps et regardez la vérification l’attraper. Le bac à sable démarre au premier Run.
🟢 Avec un agent IA
Demandez à Prova« voici mon tableur clinique — construis l’objet Surv(time, status), vérifie si mon statut est codé en 0/1 ou 1/2, et valide les temps et les ID avant que j’ajuste une courbe de Kaplan-Meier » — elle répond avec du code survival que vous pouvez exécuter sur vos propres données et vous montre les signes de censure pour confirmer le codage. The runtime is the judge.Demander à Prova →
Problèmes courants
Votre courbe de survie semble à l’envers (tout le monde « meurt » immédiatement, ou personne). Votre codage du statut est inversé — Surv() a lu vos patients censurés comme des événements. Affichez l’objet Surv() et vérifiez les signes + : ils doivent se trouver sur les patients censurés. S’ils sont sur les événements (ou totalement absents), recodez pour que la valeur la plus grande soit l’événement (0/1 ou 1/2), puis reconstruisez. C’est le bug de survie numéro un.
survfit() génère une erreur ou écarte silencieusement des lignes. Presque toujours un temps impossible — un temps de suivi nul ou négatif provenant de dates inversées ou mal soustraites. Exécutez dat[dat$time <= 0, ] ; corrigez les dates à la source plutôt que de supprimer des lignes, car un temps négatif signale généralement une erreur de date systématique affectant plus que cette seule ligne.
Un Kaplan-Meier standard sur des données censurées par intervalle donne des courbes à l’aspect erroné. Un survfit() simple suppose des temps exacts ou censurés à droite. Si vos événements ne sont connus que comme tombant entre les visites, vous avez des données censurées par intervalle — encodez-les avec Surv(lower, upper, type = "interval2") et utilisez une méthode qui respecte l’intervalle (le NPMLE de Turnbull ou un modèle paramétrique), pas la fonction en escalier ordinaire du KM.
Questions fréquentes
NoteQu’est-ce qu’un objet Surv dans R ?
Un objet Surv est la réponse que chaque fonction de survie dans R attend — il regroupe le temps de suivi avec le statut (événement ou censuré) en un seul objet. Vous le construisez avec Surv(time, status) et le placez à gauche de la formule, par exemple survfit(Surv(time, status) ~ group, data). Une fois affiché, un + après un temps marque une observation censurée.
NoteComment coder les observations censurées dans des données de survie ?
Utilisez l’indicateur de statut. Surv() accepte 0 = censuré / 1 = événementou1 = censuré / 2 = événement (une valeur logique FALSE/TRUE fonctionne aussi) — il infère la convention, et la valeur la plus grande est toujours l’événement. Une ligne censurée signifie que le sujet était sans événement au dernier contact, donc son temps est une borne inférieure. Confirmez le codage en affichant l’objet Surv() : les signes + doivent tomber sur les sujets censurés.
NoteQuelle est la différence entre censure à droite, à gauche et par intervalle ?
La censure à droite (la valeur par défaut) : l’événement ne s’est pas encore produit au dernier contact — le temps est une borne inférieure. La censure à gauche : l’événement s’est déjà produit avant la première observation — le temps est une borne supérieure (type = "left"). La censure par intervalle : l’événement s’est produit entre deux moments d’évaluation, connu seulement à une fenêtre près (type = "interval2", donnant les temps inférieur et supérieur). La plupart des données cliniques sont censurées à droite ; les études fondées sur les visites produisent souvent des données de progression censurées par intervalle.
NoteQu’est-ce que le format de processus de comptage (start, stop, event) ?
C’est une disposition à plusieurs lignes par sujet où chaque ligne est un intervalle de temps (start, stop] avec un indicateur event à stop. Vous construisez la réponse avec Surv(start, stop, event). C’est requis pour les covariables dépendantes du temps (la covariable prend une valeur différente dans chaque intervalle) et les événements récurrents (un sujet connaît l’événement plus d’une fois). Une ligne ordinaire à intervalle unique (0, time, status) n’en est que le cas particulier.
NoteComment vérifier que mes données de survie sont correctes avant de modéliser ?
Exécutez cinq vérifications en base R : (1) tous les temps positifs (time <= 0 signale les valeurs impossibles) ; (2) le statut est un code propre sans valeurs égarées ni NA (table(status)) ; (3) le codage de l’événement est dans le bon sens (l’affichage de Surv() montre + sur les lignes censurées) ; (4) aucun ID dupliqué sauf s’il s’agit de données de processus de comptage ; et (5) le type de censure correspond à la structure des données. Une seule mauvaise ligne biaise silencieusement chaque courbe et chaque hazard ratio.
Testez vos connaissances
ImportantPratique
Construisez-le et lisez-le. Dans la cellule interactive ci-dessous, construisez un objet Surv() à partir de ces cinq patients — time = c(8, 12, 5, 20, 15), status = c(1, 0, 1, 0, 1) (0 = censuré, 1 = événement). Quels patients portent un +, et qu’est-ce que cela signifie sur leur temps de l’événement réel ?
Repérez le bug. La courbe de Kaplan-Meier d’un collègue chute à zéro presque immédiatement. Il a codé status = 1 pour « vivant au dernier suivi » et status = 2 pour « décédé ». Qu’est-ce que Surv() a traité comme l’événement, et comment devrait-il le corriger ?
NoteIndice
Affichez l’objet Surv() et regardez où tombent les signes + — ce sont les patients censurés (sans événement au dernier contact). Pour la question 2, rappelez-vous que Surv() traite toujours la valeur de statut la plus grande comme l’événement.
Le + tombe sur les patients 2 (temps 12) et 4 (temps 20) — les censurés. Leurs temps sont des bornes inférieures : le patient 4 était sans événement à 20 et pourrait survivre bien plus longtemps.
Pour la question 2 : le collègue a utilisé 1 = vivant (censuré), 2 = décédé (événement) — un codage Surv()valide (plus grand = événement). Cette partie est donc correcte. Si la courbe s’effondre quand même, le vrai bug est l’erreur opposée : fournir une colonne 1 = décédé, 0 = vivant en supposant que 1 = censuré. La correction est toujours la même — affichez l’objet Surv() et vérifiez que les signes + se trouvent sur les patients censurés ; s’ils n’y sont pas, recodez pour que la valeur la plus grande soit l’événement et reconstruisez.
AstuceVérification rapide
Vous construisez Surv(time, status) et l’affichage montre un + après presque chaque temps. Le jeu de données est une cohorte où la plupart des patients sont décédés pendant le suivi. Qu’est-ce qui a mal tourné ?
NoteAfficher la réponse
Le codage du statut est inversé. Un + marque un patient censuré, donc « un + sur presque chaque ligne » signifie que Surv() traite presque tout le monde comme censuré — mais vous avez dit que la plupart des patients sont décédés. Votre indicateur d’événement est inversé (par exemple, vous avez passé 1 = vivant là où l’événement devrait être le code le plus grand). Recodez pour que l’événement soit la valeur la plus grande (0/1 ou 1/2) et reconstruisez ; les signes + ne devraient alors apparaître que sur les patients réellement censurés.
Conclusion
Vous savez désormais transformer un tableur clinique brut en un jeu de données de survie prêt à analyser : regroupez le temps de suivi et le résultat dans un objet Surv(time, status), codez correctement le statut (le piège 0/1 vs 1/2, confirmé par les signes + sur les lignes censurées), gérez la censure à droite, à gauche et par intervalle avec le type correspondant, structurez les données dépendantes du temps et récurrentes dans la disposition du processus de comptage (start, stop, event), et exécutez une courte validation en base R pour les temps impossibles, les mauvais codes de statut, les ID dupliqués et les ex æquo. Avec des données propres et correctement encodées, vous êtes prêt à estimer votre première courbe de Kaplan-Meier.
Prouvez que vous savez le faire. Maîtrisez toute la série Analyse de survie en R — suivez votre parcours, construisez des projets et obtenez un certificat.
Chaque résultat de cette page a été produit par le code montré, exécuté au moment du build contre un environnement R figé — modifiez n’importe quel bloc et faites Run pour le reproduire vous-même.
@online{2026,
author = {},
title = {Formater des données de survie dans R : objet Surv(), censure
et validation},
date = {2026-06-26},
url = {https://www.datanovia.com/learn/biostatistics/survival-analysis/preparing-survival-data},
langid = {fr}
}
