Le modèle mémoire concurrent de OCaml 5 est conçu pour garantir la sûreté du typage et la sûreté mémoire même en présence de courses critiques (data races) entre fils d'exécution. Ce choix de conception impose des choix techniques précis dans l'implémentation du compilateur et de l'environnement d'exécution du langage. Mais il impose aussi, et c'est le sujet du présent article, des changements dans la façon d'écrire les programmes utilisateurs qui utilisent des constructions non sûres comme Array.unsafe_get et Array.unsafe_set pour des raisons de performance. Même si une structure de données est conçue pour être utilisée de façon séquentielle uniquement, le documente et ne fournit aucune garantie sur un usage concurrent incorrect, elle doit faire les bons choix d'implémentation pour préserver la sûreté mémoire même dans ce cas d'usage incorrect. Des implémentations parfaitement correctes pour OCaml 4 deviennent invalides en OCaml 5. Nous présentons ici une partie de l'implémentation du module Dynarray de tableaux redimensionnables qui a été intégré à la bibliothèque standard de OCaml 5.2. Nous expliquons comment plusieurs choix d'implémentation habituels chez les utilisateurs experts du langage deviennent invalides dans un contexte concurrent. Nous présentons une façon de raisonner sur ces implémentations (≪correct tout seul, sûr à plusieurs≫), comme un modèle mental informel que nous avons utilisé pour écrire ce code, mais aussi dans une formalisation Coq utilisant la logique de séparation Iris. Nous avons développé et vérifié le noyau de Dynarray en Iris, et montrons comment organiser les spécifications pour exprimer et vérifier de façon simple et claire cette nouvelle propriété de correction.