The problem is the tikzmark tests whether or not the semicolon is active and proceeds accordingly. Now, the babel package makes the semicolon active when frenchb is active. tikzmark copes fine with that because the test is true and it proceeds on that basis. However, the babel TikZ library tries to handle active characters in code in TikZ pictures, too, so its attempts to avoid the issues caused by the babel package making the semicolon active conflict with the attempts of tikzmark to avoid the same issues. Essentially two things trying to avoid the problems end up counteracting each other.
Note that I do not understand this well enough to give a blow-by-blow account and even the above gesturing at one might be mistaken, but something like this seems to be going on.
The real issue here, I think, is that tikzmark should not assume that if the semicolon is active when \tikzmark is used, it will also be active inside tikzpictures because this will not typically be true if the babel TikZ library is used. Since this is a standard recommendation when documents use Babel configurations which make characters active, tikzmark essentially breaks code written in accordance with best practice.
I think tikzmark should test to see which active characters are being handled for code inside tikzpictures. This approach will not guarantee no breakage, but it should prevent breakage in standard cases where uses simply load the babel TikZ library and rely on it to set things up correctly.
You can workaround the problem by redefining \tikzmark. For example,
\makeatletter
\renewcommand\tikzmark@outside[2][]{%
\ifnum\catcode`\;=\active
\iftikz@handle@active@code
\let\tikzmark@next=\tikzmark@nonactive
\else
\let\tikzmark@next=\tikzmark@active
\fi
\else
\let\tikzmark@next=\tikzmark@nonactive
\fi
\tikzmark@next{#1}{#2}%
}
\makeatother
appears to solve the problem in the MWE, at least, and I hope should workaround it in real documents as well. You might also need to test whether TikZ is handling active characters in nodes. However, this should not matter in the standard case and would need, I think, to be customised for specific cases. In the standard case, where the babel library is used, active characters are handled in both code and nodes, so testing one is sufficient. Moreover, in the MWE, at least, handling active characters in nodes but not code did not reproduce the error, which is why I've tested specifically for the handling in code which causes the problem.
I would, however, recommend reporting this issue to tikzmark's author as there is almost certainly a much more elegant way to handle this issue than the one I've come up with here.
Complete example:
\documentclass[frenchb]{article}
\usepackage{tikz}
\usepackage{babel}
\usetikzlibrary{babel,tikzmark}
\makeatletter
\renewcommand\tikzmark@outside[2][]{%
\ifnum\catcode`\;=\active
\iftikz@handle@active@code
\let\tikzmark@next=\tikzmark@nonactive
\else
\let\tikzmark@next=\tikzmark@active
\fi
\else
\let\tikzmark@next=\tikzmark@nonactive
\fi
\tikzmark@next{#1}{#2}%
}
\makeatother
\begin{document}
test\tikzmark{a}
Go to test%
\begin{tikzpicture}[overlay, remember picture]
\draw[->] (0,0) to ({pic cs:a});
\end{tikzpicture}%
.
\end{document}
