RNA velocity et cartographie des destins cellulaires : scVelo, CellRank et PAGA

Q: RNA velocity vs pseudotemps — quelle est la différence ?

Le pseudotemps ordonne les cellules le long d’une trajectoire mais n’a pas de direction intrinsèque — vous lui dites où est le départ en l’enracinant. La RNA velocity infère la direction du changement par cellule à partir du rapport non épissé/épissé, elle pointe donc la flèche pour vous sans racine, même quand vous ne connaissez pas l’origine. En pratique ils sont complémentaires : le pseudotemps (issu de Slingshot ou de Monocle3) donne l’ordonnancement ; la velocity donne la direction ; et CellRank peut combiner les deux.

Allez au-delà du pseudotemps — ajoutez la direction avec la RNA velocity, demandez où va chaque cellule avec CellRank, et cartographiez la topologie grossière avec PAGA, plus le chemin honnête d’interopérabilité R

Le pseudotemps ordonne les cellules mais ne vous dit pas dans quel sens elles se déplacent. La RNA velocity, si. Cette leçon explique la RNA velocity (scVelo), la cartographie des destins (CellRank 2) et la topologie (PAGA) — ce qu’elles ajoutent au-delà de Slingshot et Monocle3, pourquoi elles ont besoin de comptages épissés et non épissés, et comment vous les exécuteriez. C’est l’état de l’art Python, donc le code ici est illustratif ; vous obtenez aussi le pont R vers Python et le relais vers un environnement de calcul géré pour exécuter la velocity pour de vrai.

Date de publication

4 juillet 2026

Modifié

7 juillet 2026

Points clés

Le pseudotemps donne l’ordre ; la velocity donne la direction. Les méthodes de trajectoire comme Slingshot et Monocle3 ordonnent les cellules le long d’un continuum mais ne peuvent pas dire dans quel sens pointe la flèche du changement. La RNA velocity — la dérivée temporelle de l’état d’expression génique — récupère cette direction à partir de l’équilibre entre ARNm non épissé et épissé (La Manno et al., 2018).
La velocity a besoin d’un type de données particulier. Elle requiert des matrices de comptage épissées et non épissées, qui proviennent de velocyto ou de kallisto | bustools, et non d’une matrice de comptage gène-par-cellule ordinaire. Si vos données n’ont pas de couche non épissée, vous ne pouvez pas calculer la velocity — c’est la première chose à vérifier.
L’état de l’art est une pile Python. scVelo estime la velocity, CellRank 2 transforme la velocity en probabilités de destin (« où va chaque cellule ? »), et PAGA dessine une carte de topologie à gros grain. Ces trois outils sont Python et bâtis sur AnnData (le conteneur de données annotées).
Cette leçon est illustrative — rien ici ne s’exécute. Le workflow de velocity tourne en Python sur des données prêtes pour la velocity, que cette leçon R reproductible ne possède pas. Chaque extrait ci-dessous est montré pour la lecture, pas pour l’exécution ; copiez-les dans un véritable environnement Python avec des comptages épissés/non épissés pour reproduire les résultats.
Les utilisateurs R ne sont pas exclus. Vous pouvez transférer un objet Seurat ou SingleCellExperiment vers AnnData avec zellkonverter / anndata / sceasy, et le pont velociraptor appelle scVelo depuis R. Mais il vous faut toujours des données prêtes pour la velocity et un véritable environnement Python — la réponse pratique est donc d’exécuter la velocity dans un environnement de calcul géré, pas dans le navigateur.

Introduction

Vous avez ordonné vos cellules. Avec Slingshot ou Monocle3 vous avez ajusté une trajectoire à travers une population en cours de différenciation et attribué à chaque cellule un pseudotemps — sa position le long du continuum. Mais le pseudotemps a un angle mort : c’est un ordonnancement, pas une direction. Rien dans la géométrie d’une courbe ajustée ne vous dit si les cellules s’écoulent de l’extrémité souche vers l’extrémité différenciée ou l’inverse. Vous fournissez vous-même la direction, en enracinant la trajectoire dans un regroupement que vous croyez déjà être l’origine. Quand vous ne connaissez pas l’origine — régénération, reprogrammation, un processus pathologique qui se déroule à rebours —, le pseudotemps seul ne peut pas vous aider.

La RNA velocity supprime cet angle mort. Elle lit la direction du changement directement dans les données, cellule par cellule, et pointe une flèche vers le futur proche. Posée par-dessus, la cartographie des destins pose la question suivante — étant donné sa velocity, où chaque cellule va-t-elle le plus probablement aboutir ? —, et les méthodes de topologie dessinent une carte simplifiée de la façon dont les grands groupes de cellules se connectent. Ensemble, elles constituent le niveau au-delà de l’ordonnancement que vous possédez déjà.

Il y a une complication honnête, et elle façonne toute cette leçon. Les outils matures et bien validés pour la velocity, la cartographie des destins et la topologie sont des paquets Python, et ils ont besoin d’un type d’entrée — des comptages épissés et non épissés — qu’une matrice de comptage standard de séquençage d’ARN single-cell (scRNA-seq) ne contient pas. À cause de cela, cette leçon enseigne les méthodes de façon illustrative : aucun code ici n’est exécuté. Nous expliquons ce que fait chaque outil et montrons exactement comment vous l’appelleriez, puis nous confions l’exécution à un véritable environnement Python. La section pourquoi rien ici ne s’exécute rend le raisonnement explicite — elle fait partie de la leçon, ce n’est pas une excuse.

Si vous n’avez pas encore rencontré les méthodes d’ordonnancement sur lesquelles ceci s’appuie, lisez d’abord les analyses approfondies Slingshot et Monocle3 ainsi que le guide de choix Slingshot vs Monocle3. Cette leçon suppose que vous avez déjà une trajectoire et que vous voulez lui ajouter une direction.

Ce que la RNA velocity mesure réellement

L’idée est élégante et repose sur un fait de biologie moléculaire. Quand un gène est transcrit, la cellule fabrique d’abord un pré-ARN messager non épissé (pré-ARNm, portant encore des introns), puis le spliceosome retire les introns pour produire un ARNm épissé mature, qui est finalement dégradé. Les protocoles scRNA-seq standard capturent les deux espèces — vous pouvez compter séparément les reads qui s’alignent à cheval sur les jonctions intron–exon (non épissé) et ceux qui s’alignent sur les transcrits matures (épissé).

Cette séparation est toute l’astuce. Considérez un gène dans une cellule :

Si le gène vient d’être activé, le pré-ARNm non épissé s’accumule plus vite qu’il ne peut être épissé et dégradé — le rapport non épissé/épissé est donc au-dessus de sa valeur stationnaire. Le gène est en cours d’induction : son futur niveau épissé va monter.
Si le gène vient d’être désactivé, la production de non épissé chute, le pool épissé existant continue de se dégrader, et le rapport passe en dessous de l’état stationnaire. Le gène est en cours de répression : son futur niveau épissé va baisser.

Faites cela pour chaque gène et vous obtenez, pour chaque cellule, un vecteur de velocity en haute dimension — le taux de changement prédit de son état d’expression pour les quelques heures à venir (La Manno et al., 2018). Projetez ces vecteurs sur votre uniform manifold approximation and projection (UMAP, la carte en 2-D) et vous obtenez les fameuses lignes de courant de velocity : des flèches qui s’écoulent à travers l’embedding, montrant la direction de la différenciation sans que vous ayez à enraciner quoi que ce soit.

La relation entre ARNm non épissé et épissé pour un gène unique est souvent représentée sous forme de portrait de phase — un nuage de cellules avec le niveau épissé en abscisse et le niveau non épissé en ordonnée. Les cellules au-dessus de la droite diagonale d’état stationnaire induisent le gène ; les cellules en dessous le répriment. scVelo ajuste ce portrait de phase par gène et en déduit la velocity.

La méthode originale estimait la velocity à partir d’un modèle à l’état stationnaire (déterministe). scVelo l’a généralisée : son modèle stochastique utilise les moments d’ordre deux de la distribution non épissé/épissé, et son modèle dynamique résout la cinétique complète de l’épissage avec un algorithme d’espérance-maximisation (EM, une procédure itérative d’ajustement par vraisemblance) — ce qui rend la velocity valide même pour des états cellulaires transitoires qui ne sont pas à l’état stationnaire (Bergen et al., 2020).

Le workflow velocity-vers-destin en un coup d’œil

Avant tout code, voici la forme du pipeline complet — ce qui alimente quoi, des comptages épissés/non épissés bruts jusqu’aux probabilités de destin et à une carte de topologie.

flowchart TD
  raw["Comptages épissés + non épissés<br/>(velocyto / kallisto|bustools)"] --> adata["Objet AnnData<br/>(couches épissée & non épissée)"]
  adata --> moments["scVelo : moments"]
  moments --> velocity["scVelo : velocity<br/>(stochastique / dynamique)"]
  velocity --> vgraph["scVelo : graphe de velocity"]
  vgraph --> stream["Lignes de courant de velocity<br/>sur l'UMAP"]
  vgraph --> vk["CellRank : VelocityKernel<br/>+ ConnectivityKernel"]
  vk --> gpcca["CellRank : estimateur GPCCA<br/>macro-états -> états terminaux"]
  gpcca --> fate["Probabilités de destin par cellule<br/>(où va chaque cellule ?)"]
  adata --> paga["scanpy : PAGA"]
  paga --> topo["Graphe de topologie à gros grain<br/>des regroupements"]

Figure 1

Lisez-le de gauche à droite en trois étapes : scVelo transforme les comptages épissés/non épissés en velocity et en lignes de courant ; CellRank transforme la velocity en probabilités de destin ; PAGA fournit une carte de topologie grossière et indépendante. Les trois sections suivantes montrent le code illustratif de chaque étape.

Estimer la velocity avec scVelo

scVelo (Bergen et al., 2020) est l’estimateur de velocity standard. Il travaille sur un objet AnnData (adata) qui porte des couches spliced et unspliced — les deux matrices produites en amont par velocyto ou kallisto | bustools. Le workflow tient en quatre appels plus un tracé : prétraiter et normaliser, calculer les moments utilisés par le modèle, estimer la velocity, construire le graphe de velocity, puis dessiner les lignes de courant.

# ILLUSTRATIVE — Python, not executed here. Run in a Python environment
# with an AnnData object that has `spliced` and `unspliced` layers.
import scvelo as scv

# `adata` already has spliced/unspliced layers (from velocyto or kallisto|bustools)
# and a UMAP in adata.obsm["X_umap"], plus a cluster label in adata.obs["clusters"].

# 1. Filter genes and normalize spliced + unspliced counts
scv.pp.filter_and_normalize(adata, min_shared_counts=20, n_top_genes=2000)

# 2. First/second-order moments among nearest neighbours (needed by the model)
scv.pp.moments(adata, n_pcs=30, n_neighbors=30)

# 3. Estimate velocity. mode="stochastic" uses second moments; "dynamical"
#    solves the full splicing kinetics with EM (run scv.tl.recover_dynamics first).
scv.tl.velocity(adata, mode="stochastic")

# 4. Build the velocity graph (cosine similarities of velocity vs cell transitions)
scv.tl.velocity_graph(adata)

# 5. Project velocity onto the UMAP as streamlines
scv.pl.velocity_embedding_stream(adata, basis="umap", color="clusters")

Chaque étape correspond à la biologie ci-dessus. filter_and_normalize conserve les gènes ayant assez de signal épissé et non épissé et normalise les deux couches. moments lisse les comptages à travers les voisins de chaque cellule — le modèle stochastique a besoin des moments d’ordre deux (les variances), le modèle déterministe seulement des premiers. velocity ajuste le portrait de phase par gène et en déduit le vecteur de velocity par cellule. velocity_graph calcule, pour chaque paire de cellules voisines, si le vecteur de velocity pointe vers ce voisin — c’est ce qui permet de projeter les flèches en 2-D. Enfin, velocity_embedding_stream dessine les lignes de courant sur votre UMAP.

Pour les systèmes transitoires (développement, réponse à une perturbation), préférez le modèle dynamique : appelez d’abord scv.tl.recover_dynamics(adata), puis scv.tl.velocity(adata, mode="dynamical"). Il est plus lent mais ne suppose pas l’état stationnaire, qui est précisément l’hypothèse qui se brise pendant une différenciation rapide.

Cartographier les probabilités de destin avec CellRank

Les lignes de courant de velocity sont un résumé visuel. CellRank (Lange et al., 2022 ; Weiler et al., 2024) les transforme en cartographie des destins quantitative : pour chaque cellule, il calcule une probabilité de destin — la chance que la cellule, en suivant sa velocity, aboutisse dans chaque état terminal. Cela répond directement à « où va chaque cellule ? » d’une façon qu’un tracé de lignes de courant ne peut pas.

CellRank 2 est construit autour d’une conception nette en deux parties — les kernels calculent une matrice de transition cellule-à-cellule, et les estimateurs l’analysent :

# ILLUSTRATIVE — Python, not executed here.
import cellrank as cr

# A) A VelocityKernel builds a transition matrix from scVelo's velocity...
vk = cr.kernels.VelocityKernel(adata).compute_transition_matrix()

# B) ...combined with a ConnectivityKernel (expression similarity) for robustness.
ck = cr.kernels.ConnectivityKernel(adata).compute_transition_matrix()
combined_kernel = 0.8 * vk + 0.2 * ck

# C) A GPCCA estimator coarse-grains that matrix into macrostates
#    (Generalized Perron Cluster Cluster Analysis).
g = cr.estimators.GPCCA(combined_kernel)
g.compute_macrostates(n_states=6, cluster_key="clusters")

# D) Classify some macrostates as terminal (the fates), then compute,
#    for every cell, its probability of reaching each terminal state.
g.predict_terminal_states()
g.compute_fate_probabilities()
g.plot_fate_probabilities(same_plot=False)

Le modèle mental : le VelocityKernel dit « les cellules s’écoulent dans la direction que pointe leur velocity » ; le ConnectivityKernel ajoute « les cellules se déplacent aussi entre voisins transcriptionnellement similaires ». Les pondérer (ici 0.8 / 0.2) rend la matrice de transition robuste aux vecteurs de velocity bruités. L’estimateur GPCCA trouve alors les macro-états (des groupes métastables), signale ceux sans flux sortant comme états terminaux, et calcule les probabilités de destin en simulant des marches aléatoires le long de la matrice de transition. Le résultat est une probabilité par cellule et par destin que vous pouvez tracer, corréler à des gènes, ou utiliser pour trouver les pilotes de lignée. CellRank 2 généralise cela au-delà de la velocity — le même estimateur tourne sur un kernel de pseudotemps ou un kernel de similarité — mais le kernel de velocity est le cas d’usage classique du destin dirigé.

Dessiner la topologie avec PAGA

La RNA velocity et CellRank opèrent à la résolution single-cell. Parfois vous voulez l’inverse : une carte grossière de la façon dont les grands groupes de cellules se connectent — quels regroupements sont adjacents sur la variété, et lesquels sont des îlots. PAGA (partition-based graph abstraction) (Wolf et al., 2019) fournit exactement cela. Il traite chaque regroupement comme un nœud et trace une arête pondérée entre deux regroupements proportionnelle à la connexion de leurs cellules, donnant un graphe simplifié qui préserve la topologie globale qu’un UMAP peut déformer.

PAGA vit dans scanpy, la boîte à outils single-cell généraliste :

# ILLUSTRATIVE — Python, not executed here.
import scanpy as sc

# `adata` has a neighbourhood graph and a cluster label (here Leiden clusters).
sc.tl.paga(adata, groups="leiden")

# The abstracted graph: nodes = clusters, edge weight = connectivity
sc.pl.paga(adata, color="leiden")

# Optionally lay out a PAGA-initialized force-directed graph for a topology-faithful embedding
sc.tl.draw_graph(adata, init_pos="paga")
sc.pl.draw_graph(adata, color="leiden")

PAGA est complémentaire de la velocity, pas un concurrent. Il ne donne aucune direction — c’est une connectivité non orientée — mais il répond proprement à une question différente : ce jeu de données est-il une seule variété connectée ou plusieurs îlots, et quels regroupements font le pont vers quels autres ? Un schéma courant consiste à lire d’abord le graphe PAGA pour comprendre la topologie grossière, puis à utiliser la velocity et CellRank pour poser dessus la direction et le destin. Utiliser PAGA pour initialiser une disposition dirigée par les forces (init_pos="paga") — ou un UMAP via sc.tl.umap(adata, init_pos="paga") — produit aussi des embeddings dont la structure globale est plus fiable pour le travail de trajectoire.

Pourquoi cette leçon est illustrative

Toutes les autres leçons de trajectoire de ce site exécutent leur code et committent la sortie exacte. Celle-ci ne le fait pas, et la raison mérite d’être comprise — c’est une propriété réelle de l’analyse de velocity, pas une limitation du site.

1. Les données. La velocity a besoin de matrices de comptage épissées et non épissées, produites par une étape de quantification spéciale — velocyto ou kallisto | bustools exécutés sur les reads, séparant le signal intronique (non épissé) de l’exonique (épissé). Une matrice de comptage gène-par-cellule ordinaire — celle qu’utilise toute autre leçon de cette série — ne contient pas la couche non épissée et ne peut tout simplement pas produire la velocity. Les jeux de données prêts pour la velocity sont distribués sous forme d’objets AnnData Python (.h5ad) avec ces deux couches déjà calculées.

2. L’environnement. Le pont R sanctionné, velociraptor (Bioconductor), exécute scVelo depuis R — mais il le fait en provisionnant un environnement conda au moment du rendu via basilisk. Cela signifie un téléchargement réseau et une pile Python matérialisée pendant le build, ce qui n’est ni déterministe hors ligne ni reproductible de la façon byte-identique qu’exige notre freeze de rendu commité.

3. La stochasticité. L’estimation de la velocity, le graphe de velocity et les probabilités de destin par marche aléatoire de CellRank sont stochastiques. Même figées sur une graine, les flèches et les probabilités projetées peuvent varier d’une version et d’une plateforme à l’autre, donc un nombre « exécuté » ici ne se reproduirait pas de façon stable.

Mis bout à bout, le choix honnête et reproductible est d’enseigner le standard Python de façon illustrative et de confier l’exécution à un environnement conçu pour cela. Ce n’est pas un contournement — c’est la façon dont cette analyse se fait réellement en pratique : sur une véritable pile Python, avec de véritables données prêtes pour la velocity.

Le chemin d’interopérabilité R et de calcul géré

Rien de tout cela n’exclut les utilisateurs R ; cela signifie simplement que l’exécution se passe en Python. Deux choses comblent l’écart.

Transférez votre objet vers AnnData. Si votre analyse vit dans un objet Seurat ou SingleCellExperiment (SCE), vous pouvez le convertir au format AnnData Python qu’attendent scVelo, CellRank et scanpy :

# ILLUSTRATIVE — shows the bridge; run where the Python stack is available.

# Option 1: zellkonverter writes a SingleCellExperiment to an .h5ad file.
library(zellkonverter)
writeH5AD(sce, file = "for_scvelo.h5ad")   # then read it in Python: adata = sc.read_h5ad(...)

# Option 2: the anndata R package + reticulate build/inspect AnnData from R.
library(anndata)
ad <- read_h5ad("for_scvelo.h5ad")

# Option 3: sceasy::convertFormat() converts Seurat <-> AnnData directly.
# sceasy::convertFormat(seurat_obj, from = "seurat", to = "anndata", out = "for_scvelo.h5ad")

Point crucial, la conversion déplace l’objet, pas la biologie manquante. Si votre SCE n’a pas d’assay non épissé, l’AnnData résultant n’a pas de couche non épissée, et la velocity reste impossible — vous devez revenir en arrière et re-quantifier avec velocyto / kallisto | bustools pour obtenir en premier lieu des comptages épissés et non épissés.

Exécutez la velocity dans un environnement de calcul géré. Parce que la velocity a besoin d’un véritable environnement Python (scVelo, CellRank, scanpy — ou velociraptor + basilisk depuis R) et de données prêtes pour la velocity, son foyer pratique est un environnement de calcul géré : une session Python hébergée ou un conteneur avec la pile préinstallée et les données .h5ad montées. C’est là que vous copiez les extraits ci-dessus, que vous les exécutez pour de vrai, et que vous obtenez les lignes de courant et les probabilités de destin. Cette leçon vous donne la carte ; l’exécution appartient à cet endroit.

Problèmes fréquents

« Ma matrice de comptage n’a pas de couche non épissée. » C’est le blocage le plus courant, et il n’est pas réparable en aval. La RNA velocity est calculée à partir du rapport du pré-ARNm non épissé à l’ARNm épissé, donc les deux doivent être quantifiés à partir des reads. Une matrice gène-par-cellule standard (issue de la sortie filtrée de Cell Ranger, par exemple) ne porte que les comptages totaux. Vous devez relancer la quantification avec velocyto (qui ajoute une séparation épissé/non épissé/ambigu) ou kallisto | bustools dans son workflow lamanno/noyau. Pas de couche non épissée, pas de velocity — vérifiez cela en premier, avant toute chose.

« Les flèches de velocity pointent dans le mauvais sens / la confiance est faible. » La velocity peut réellement échouer quand ses hypothèses se brisent : une capture non épissée très faible (courante dans certaines chimies 3′), un système loin de l’état stationnaire sous le modèle déterministe, ou des gènes à cinétique inhabituelle. Diagnostiquez avec scv.tl.velocity_confidence() et inspectez les portraits de phase par gène (scv.pl.velocity(adata, ["GeneA", "GeneB"])) — si les portraits ne montrent pas la trajectoire courbée attendue, l’estimation n’est pas fiable. Passer au modèle dynamique (scv.tl.recover_dynamics puis mode="dynamical") aide pour les états transitoires ; si les flèches contredisent toujours la biologie connue, traitez la velocity comme non concluante pour ce jeu de données plutôt que de forcer une interprétation.

« Je travaille uniquement en R — comment puis-je même exécuter ceci ? » Vous faites le pont, puis vous exécutez en Python. Convertissez votre objet en AnnData (zellkonverter, anndata ou sceasy), ou pilotez scVelo depuis R avec velociraptor — mais dans tous les cas il vous faut des données prêtes pour la velocity (épissé + non épissé) et un véritable environnement Python, donc prévoyez de l’exécuter dans une session de calcul géré plutôt que dans un rendu R léger. Il n’existe aujourd’hui aucune voie pur-R, sans Python, vers la RNA velocity.

Questions fréquentes

Puis-je calculer la RNA velocity en R ?

Pas nativement — l’estimation se passe en Python. Le paquet Bioconductor velociraptor vous permet d’appeler scVelo depuis R via sa fonction scvelo(), mais sous le capot il provisionne un environnement Python avec basilisk et convertit votre objet avec zellkonverter. Vous pouvez donc piloter la velocity depuis une session R, mais vous exécutez toujours Python, et il vous faut toujours des comptages épissés et non épissés plus un véritable environnement pour cela. Il n’existe aucune implémentation pur-R de la RNA velocity.

Ai-je besoin de comptages épissés et non épissés pour la RNA velocity ?

Oui — ils sont obligatoires. La RNA velocity est définie à partir de l’équilibre entre le pré-ARN messager non épissé et l’ARNm épissé mature, donc les deux doivent être quantifiés. Vous les générez avec velocyto ou kallisto | bustools, qui séparent les reads introniques (non épissé) des exoniques (épissé). Une matrice de comptage gène-par-cellule standard ne contient pas la couche non épissée, elle ne peut donc pas produire de velocity quel que soit l’outil que vous lui pointez dessus.

RNA velocity vs pseudotemps — quelle est la différence ?

Le pseudotemps ordonne les cellules le long d’une trajectoire mais n’a pas de direction intrinsèque — vous lui dites où est le départ en l’enracinant. La RNA velocity infère la direction du changement par cellule à partir du rapport non épissé/épissé, elle pointe donc la flèche pour vous sans racine, même quand vous ne connaissez pas l’origine. En pratique ils sont complémentaires : le pseudotemps (issu de Slingshot ou de Monocle3) donne l’ordonnancement ; la velocity donne la direction ; et CellRank peut combiner les deux.

Que fait CellRank que scVelo ne fait pas ?

scVelo estime la velocity et dessine des lignes de courant — un sens visuel du flux. CellRank transforme ce flux en cartographie des destins quantitative : il construit une matrice de transition à partir de la velocity (son VelocityKernel), l’agrège en macro-états et états terminaux (l’estimateur GPCCA), et calcule par cellule une probabilité de destin d’atteindre chaque état terminal. Là où scVelo montre la direction, CellRank vous dit, cellule par cellule, où chaque cellule va le plus probablement aboutir.

À quoi sert PAGA ?

PAGA (partition-based graph abstraction) construit une carte à gros grain de vos données : chaque regroupement devient un nœud, et les poids des arêtes encodent la connexion des regroupements entre eux. C’est l’outil pour lire la topologie globale — savoir si le jeu de données est une seule variété connectée ou plusieurs îlots, et quels regroupements font le pont vers quels autres. Il ne donne aucune direction (il est non orienté), il complète donc la RNA velocity plutôt que de la remplacer ; un workflow courant lit d’abord la topologie PAGA, puis ajoute la velocity et le destin par-dessus.

Testez vos connaissances

À vous de jouer : planifier une analyse de velocity à partir d’un objet R

Vous avez un objet Seurat de cellules en cours de différenciation avec un UMAP et des regroupements Leiden, produit par le pipeline scRNA-seq standard. Un collaborateur vous demande d’« ajouter des flèches de RNA velocity et de nous dire quels progéniteurs vont vers quel destin ». Écrivez le plan : ce que vous devez d’abord vérifier sur les données, comment vous transféreriez l’objet vers le côté Python, quel outil calcule les flèches, lequel calcule les destins, et où vous l’exécuteriez réellement. (C’est un exercice de planification — il n’y a aucun code à exécuter ici.)

Indice

Commencez par la question des données, pas par les outils : l’objet porte-t-il une couche non épissée ? Un objet Seurat standard bâti à partir d’une matrice filtrée de Cell Ranger n’en a pas. Puis réfléchissez au pont vers AnnData, à la division du travail entre scVelo (velocity/flèches) et CellRank (probabilités de destin), et à pourquoi l’exécution doit quitter le rendu R léger.

Solution (conceptuelle — illustrative, non exécutée)

Vérifiez d’abord les données. Un objet Seurat standard n’a que les comptages totaux — aucune couche non épissée — donc la velocity est impossible en l’état. Vous devez re-quantifier les reads avec velocyto ou kallisto | bustools pour obtenir des matrices épissée et non épissée. C’est l’étape bloquante ; si elle ne peut pas être faite, la velocity est hors de portée.
Faites le pont vers AnnData. Convertissez l’objet (re-quantifié) en .h5ad — zellkonverter::writeH5AD() depuis un SCE, ou sceasy::convertFormat() depuis Seurat — pour que la pile Python puisse le lire.
Calculez les flèches avec scVelo : filter_and_normalize → moments → velocity(mode="stochastic") (ou dynamical pour les états transitoires) → velocity_graph → velocity_embedding_stream.
Calculez les destins avec CellRank : un VelocityKernel (combiné à un ConnectivityKernel) → estimateur GPCCA → compute_macrostates → predict_terminal_states → compute_fate_probabilities. Les probabilités de destin répondent à « quels progéniteurs vont vers quel destin ».
Exécutez-le dans un environnement de calcul géré — une session Python hébergée ou un conteneur avec scVelo/CellRank et le .h5ad monté — pas dans le navigateur et pas dans un rendu R léger, parce que la velocity a besoin d’un véritable environnement Python plus des données prêtes pour la velocity.

Vérification rapide : votre objet Seurat a été construit à partir d’une matrice de comptage filtrée standard de Cell Ranger. Pourquoi ne pouvez-vous pas calculer la RNA velocity directement à partir de lui ?

A. Les objets Seurat sont incompatibles avec scVelo, donc aucune velocity n’est possible depuis un objet Seurat. B. La matrice de comptage filtrée n’a que les comptages totaux (épissés) et aucune couche de pré-ARNm non épissé, dont la RNA velocity a besoin — vous devez d’abord re-quantifier avec velocyto ou kallisto | bustools. C. La RNA velocity a besoin d’un pseudotemps, et vous n’avez pas encore exécuté Slingshot.

Afficher la réponse

B. La RNA velocity est calculée à partir du rapport de l’ARNm non épissé sur l’épissé, et une matrice de comptage filtrée standard ne porte que les comptages totaux — il n’y a aucune couche non épissée avec laquelle travailler. Le correctif est en amont : relancez la quantification avec velocyto ou kallisto | bustools pour que les deux espèces soient comptées. (A est faux — un objet Seurat peut être ponté vers AnnData une fois qu’il a les couches ; C est faux — la velocity infère la direction par elle-même et ne requiert pas de pseudotemps précalculé.)

Conclusion

Le pseudotemps vous a dit l’ordre d’une population en cours de différenciation ; la RNA velocity vous dit la direction. scVelo lit cette direction à partir de l’équilibre non épissé/épissé et la dessine sous forme de lignes de courant, CellRank la transforme en probabilités de destin par cellule qui répondent à « où va chaque cellule ? », et PAGA cartographie la topologie grossière sur laquelle repose l’ensemble. Ce sont des outils Python qui ont besoin de comptages épissés et non épissés, donc cette leçon les a enseignés honnêtement — de façon illustrative, sans rien exécuter — et vous a orienté vers le pont R-vers-AnnData et l’environnement de calcul géré où la velocity s’exécute réellement. Quand vos données ont une couche non épissée et que vous disposez d’une véritable pile Python, les extraits ici sont le workflow ; jusque-là, la direction qu’ils ajoutent est la raison de recourir à la velocity une fois que l’ordonnancement seul ne suffit plus.

Leçons connexes

Trajectoire & pseudotemps avec Slingshot — la méthode R qui ordonne les cellules le long de courbes de lignées ramifiées ; la velocity ajoute la direction que Slingshot ne peut pas inférer seul. · Analyse de trajectoire avec Monocle3 — apprend un graphe principal et un pseudotemps en R ; associez-la à la velocity pour un destin dirigé. · Slingshot vs Monocle3 — choisissez entre les deux méthodes d’ordonnancement R avant d’ajouter la velocity par-dessus. · Clustering & UMAP — construit l’embedding et les regroupements sur lesquels sont tracés les lignes de courant de velocity et PAGA. · Bioinformatique — le pilier.
Où cela s’inscrit : clustering & UMAP → gènes marqueurs & annotation → ordonnancement en pseudotemps (avec Slingshot ou Monocle3) → RNA velocity, cartographie des destins & topologie — cette leçon clôt le bloc trajectoire en ajoutant la direction et le destin à l’ordonnancement.

🟢 Avec un agent IA

Demandez à Prova « j’ai un objet Seurat de cellules en cours de différenciation et je veux la RNA velocity — ai-je les bonnes données, et quel est le plan exact pour exécuter scVelo et CellRank à partir d’un point de départ R ? » — elle vérifie si votre objet porte une couche non épissée, vous guide à travers le pont zellkonverter / sceasy vers AnnData, et détaille les appels scVelo et CellRank 2 que vous exécuteriez dans un environnement Python. The runtime is the judge. Demander à Prova →

Cette page vous a-t-elle été utile ?

Note

Cette leçon est illustrative, par conception. La RNA velocity, la cartographie des destins avec CellRank et PAGA s’exécutent en Python sur des matrices de comptage épissées/non épissées, que les pipelines scRNA-seq standard — et les données de cette leçon — ne produisent pas. Le code ici est donc montré pour la lecture, non exécuté : aucun nombre ni tracé n’est reproduit sur cette page. Copiez les extraits dans un environnement Python (ou velociraptor + basilisk) avec des données prêtes pour la velocity pour les exécuter pour de vrai. Le raisonnement est détaillé dans pourquoi cette leçon est illustrative.

Références

La Manno, G., et al. (2018). RNA velocity of single cells. Nature, 560, 494–498. https://doi.org/10.1038/s41586-018-0414-6
Bergen, V., et al. (2020). Generalizing RNA velocity to transient cell states through dynamical modeling (scVelo). Nature Biotechnology, 38, 1408–1414. https://doi.org/10.1038/s41587-020-0591-3
Lange, M., et al. (2022). CellRank for directed single-cell fate mapping. Nature Methods, 19, 159–170. https://doi.org/10.1038/s41592-021-01346-6
Weiler, P., et al. (2024). CellRank 2: unified fate mapping in multiview single-cell data. Nature Methods, 21, 1196–1205. https://doi.org/10.1038/s41592-024-02303-9
Wolf, F. A., et al. (2019). PAGA: graph abstraction reconciles clustering with trajectory inference through a topology preserving map of single cells. Genome Biology, 20, 59. https://doi.org/10.1186/s13059-019-1663-x

Réutilisation

CC BY-NC-SA 4.0

Citation

BibTeX

@online{2026,
  author = {},
  title = {RNA velocity et cartographie des destins cellulaires :
    scVelo, CellRank et PAGA},
  date = {2026-07-04},
  url = {https://www.datanovia.com/learn/bioinformatics/single-cell/scrnaseq-rna-velocity-fate-mapping.html},
  langid = {fr}
}

Veuillez citer ce travail comme suit :

“RNA velocity et cartographie des destins cellulaires : scVelo, CellRank et PAGA.” 2026. July 4. https://www.datanovia.com/learn/bioinformatics/single-cell/scrnaseq-rna-velocity-fate-mapping.html.