The Following patch seems to fix my problem :
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -3778,13 +3778,7 @@ comp-delete-or-replace-file
          (while
              (condition-case _
                  (progn
-                   ;; oldfile maybe recreated by another Emacs in
-                   ;; between the following two rename-file calls
-                   (if (file-exists-p oldfile)
-                       (rename-file oldfile (make-temp-file-internal
-                                             (file-name-sans-extension oldfile)
-                                             nil ".eln.old" nil)
-                                    t))
+                   (delete-file oldfile)
                    (when newfile
                      (rename-file newfile oldfile nil))
                    ;; Keep on trying.
Changed the call to rename-file to delete-file.

De : Eli Zaretskii<mailto:eliz@gnu.org>
Envoyé le :samedi 6 mars 2021 21:16
À : Andrea Corallo<mailto:akrl@sdf.org>
Cc : mmerino@outlook.fr<mailto:mmerino@outlook.fr>; 46972@debbugs.gnu.org<mailto:46972@debbugs.gnu.org>
Objet :Re: RE : RE : bug#46972: 28.0.50; [feature/native-comp] Emacs locks itself during native compilation because of permission denied

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Matt M <mmerino@outlook.fr>, 46972@debbugs.gnu.org
> Date: Sat, 06 Mar 2021 20:14:12 +0000
>
> > Hmm...  Andrea, what could that Emacs wait for?  When compilation
> > signals the error described by Matt, why doesn't Emacs exit instead of
> > waiting for something?
>
> I *think* that what might be going on here is that Emacs is trying to
> delete a stale .eln file through `comp-delete-or-replace-file'.  There
> we have some Windows specific code that I guess might loop forever.
>
> I guess somebody observing this issue will have confirm or refut this
> suspect debugging this function.

OK, I will try to reproduce this and look into the cause(s).