Procédé pour la surveillance de l’exécution d’un logiciel d’application mettant en œuvre une fonction de sécurité, comprenant la mise en œuvre d’un couplage par logiciel sur une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement (PCPU) et une seconde unité de traitement (SCPU) ayant, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement, ledit procédé comprenant - un partitionnement du logiciel d’application (EUAP) en un logiciel de démarrage et un premier logiciel d’exécution (RS) exécutant de manière séquentielle et itérative ladite fonction de sécurité sur la base d’une machine d’états au cours d’une séquence d’intervalles temporels successifs (Tdiag(i)), - une fourniture d’un second logiciel d’exécution (SRS) qui est une version potentiellement modifiée du premier logiciel d’exécution (RS) et ayant le même comportement que celui dudit premier logiciel d’exécution, - une exécution du logiciel de démarrage (STS) et du premier logiciel d’exécution (RS) par la première unité de traitement (PCPU) et une exécution du second logiciel d’exécution (SRS) par la seconde unité de traitement (SCPU), et - au cours d’un intervalle temporel (Tdiag(i)) courant de ladite séquence, une réalisation d’un traitement de contrôle (CHKPR) comprenant au moins un traitement de comparaison réalisé à la fin de l’exécution dudit second logiciel d’exécution entre des premiers résultats de l’exécution du premier logiciel d’exécution (RS) et des seconds résultats de l’exécution du second logiciel d’exécution (SRS). Procédé selon la revendication 1, dans lequel le premier logiciel d’exécution (RS) reçoit, lors une itération courante, un premier vecteur de données d’entrée courant et un premier vecteur de variables d’état courant et délivre un premier vecteur de données de sortie courant et un premier vecteur de variables d’état mis à jour courant qui seront respectivement le vecteur de données d’entrée suivant et le vecteur de variables d’état suivant pour l’itération suivante, et dans lequel le traitement de contrôle comprend : a) une sélection d’au moins une itération et pour ladite au moins une itération sélectionnée : b) un stockage du premier vecteur de données de sortie correspondant et du premier vecteur de variables d’état mis à jour correspondant dans une mémoire, c) une fourniture, au second logiciel d’exécution (SRS), du premier vecteur de données d’entrée correspondant et du premier vecteur de variables d’état correspondant, et une obtention, à partir dudit second logiciel d’exécution (SRS), à un moment ultérieur au moment auquel le premier vecteur de données de sortie correspondant et le premier vecteur de variables d’état mis à jour correspondant sont délivrés, d’un second vecteur de données de sortie correspondant et d’un second vecteur de variables d’état mis à jour correspondant, d) une comparaison dudit premier vecteur de données de sortie correspondant avec ledit second vecteur de données de sortie correspondant et une comparaison dudit premier vecteur de variables d’état mis à jour correspondant avec ledit second vecteur de variables d’état mis à jour correspondant, et e) en cas de concordance à l’étape d), une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon la revendication 2, dans lequel ledit traitement de contrôle comprend en outre : f) une réalisation, au cours dudit intervalle temporel courant de ladite séquence, d’une double exécution (DCRSO) de chaque première itération de logiciel d’exécution à l’aide du même vecteur de données d’entrée correspondant et du même vecteur de variables d’état correspondant pour les deux exécutions, et une comparaison des deux vecteurs de données de sortie et une comparaison des deux vecteurs de variables d’état mis à jour obtenus respectivement par les deux exécutions, et g) en cas de concordance à l’étape f) pour chaque double exécution de chaque première itération de logiciel d’exécution, une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon la revendication 3, dans lequel ledit traitement de contrôle comprend en outre, au cours dudit intervalle temporel courant : - h) un comptage (90) du nombre d’itérations du premier logiciel d’exécution exécutées au cours de l’exécution du second logiciel d’exécution, - i) une comparaison, à la fin de l’exécution du second logiciel d’exécution, de la valeur de comptage (Nb) avec une valeur attendue (EXNb), et - j) en cas de concordance à l’étape i), une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon la revendication 2, dans lequel ledit traitement de contrôle comprend en outre, au cours dudit intervalle temporel courant (Tdiag(i)) : - k) un stockage (SMM), pour chaque itération du premier logiciel d’exécution, du premier vecteur de données d’entrée courant correspondant, du premier vecteur de variables d’état courant correspondant, du premier vecteur de données de sortie courant correspondant et du premier vecteur de variables d’état mis à jour courant correspondant, - l) une réalisation, à la fin de l’exécution du second logiciel d’exécution, de contrôles de vraisemblance sur tous les vecteurs stockés à l’étape k), - m) en cas de contrôles réussis à l’étape l) une répétition dudit traitement de contrôle pour l’intervalle temporel suivant de ladite séquence. Procédé selon l’une quelconque des revendications 2 à 5, dans lequel ledit traitement de contrôle comprend en outre, en cas de discordance à l’étape d) et/ou f) et/ou i) et/ou en cas de contrôles non réussis à l’étape l), une délivrance d’un signal d’erreur (LCLSEM, SAEM, DCEM). Procédé selon la revendication 6, comprenant en outre une répétition dudit traitement de contrôle (CHKPR) pour l’intervalle temporel suivant de ladite séquence, en dépit de la délivrance dudit signal d’erreur (LCLSEM, SAEM, DCEM). Système sur puce, comprenant une structure d’unités de traitement asymétriques doubles, ladite structure d’unités de traitement comportant une première unité de traitement (PCPU) et une seconde unité de traitement (SCPU) ayant, en raison de ladite asymétrie, une structure matérielle différente et/ou une capacité de calcul inférieure par rapport à ladite première unité de traitement, ladite structure d’unités de traitement étant configurée pour réaliser le procédé pour la surveillance de l’exécution d’un logiciel d’application (EUAP) mettant en œuvre une fonction de sécurité selon l’une quelconque des revendications précédentes.