Citation :une des requêtes [n'est pas rollback]
J'en déduis donc qu'il y a plusieurs requêtes, contrairement à ce qu'on voit ici, donc ce n'est toujours pas le code global D'autant que là, je trouve que cela sent mauvais: tu try/catch avec un rollback dans le catch et un autre rollback dans le try "if tout s'est bien passé"? c'est pas l'usage correct d'un try/catch: le but du try/catch est de sortir ert d'insoler le flux des erreurs. Tu devrais avoir juste un "commit" en fin de "try", car tout s'est nécessairement bien passé si le try arrive à son terme, et un rollback dans le catch car si on tombe dans le catch, c'est qu'un truc a foiré (et donc, tu rollback).
D'où aussi ce que je te demandais, qui évitera encore mieux les tirs dans le vide: ouvre le ton mysql query log, et donne les requêtes qui sont exécutées sur ta page. On y verra plus clair vis-à-vis de ce que la BDD reçoit. Là, je pense simplement que la BDD reçoit le START TRANSACTION, puis le INSERT, puis le COMMIT puis l'intérieur de ton "if" doit throw un truc qui remonte dans le catch et tente de ROLLBACK alors qu'aucune transaction n'est ouverte.
Nota: perso, c'est pour cela que j'aime le fait de placer sa logique SQL et métier dans une procédure par page: je trouve que cela évite ce genre de méandres et cela structure bien proprement les choses (en échange, je reconnais que cela peut être très chiant de déboguer un procédure stockée tant les outils pour cela n'existent toujours pas, malgré des décennies de bons et loyaux service de la part du SQL).