La vérification déductive cherche à vérifier que le code d'un programme donné est conforme à une spécification formelle de son comportement prévu. Cette approche procède en générant des énoncés mathématiques dont la validité implique la conformité du programme. De tels énoncés sont généralement transmis à des prouveurs automatiques de théorèmes. Le travail présenté dans ce rapport vise à fournir une aide au programmeur dans le cas où les preuves échouent. En effet, identifier la cause d'un échec de preuve lors de la vérification déductive d'un programme est difficile: cela peut être dû soit à une erreur dans le programme, soit à une incomplétude dans les annotations du programme, ou encore à une incomplétude du prouveur lui-même. Le type de modification à effectuer pour corriger l'échec de la preuve dépend de sa catégorie, mais le prouveur ne peut à lui seul fournir de l'aide à cette catégorisation. En pratique, lors de l'utilisation d'un solveur de type SMT pour prouver une obligation de preuve, un tel solveur peut proposer un modèle à partir d'une tentative de preuve ratée, à partir duquel un contre-exemple potentiel peut être dérivé. Mais il s'avère qu'un tel contre-exemple peut être invalide, auquel cas il peut apporter plus de confusion que d'aide au programmeur. Le but de ce travail est à la fois de vérifier la validité d'un contre-exemple et de catégoriser l'échec de la preuve. Nous proposons une approche qui s'appuie sur la comparaison entre des exécutions «~RAC~» (Run-time Assertion Checking) du programme (et de ses spécifications) sous deux sémantiques différentes, en utilisant le contre-exemple comme un oracle. La première exécution RAC suit la sémantique habituelle du programme, de sorte qu'une violation d'une annotation du code indique une erreur dans le programme. La deuxième exécution RAC suit une sémantique originale dite «~à pas de géant~» qui n'exécute ni les boucles ni les appels de fonction, mais récupère à la place depuis l'oracle les valeurs de retour et les valeurs des variables modifiées. Une violation des annotations du programme observée uniquement sous l'exécution à pas de géant caractérise une incomplétude des annotations du programme. Nous avons implémenté cette approche dans la plateforme Why3 pour la vérification déductive, et nous l'avons évalué sur une base d’exemples tirés de la littérature antérieure.