Python 3 simple external sort with heapq
Nit: running isort would organize your imports,
to reduce git merge conflicts.
The split_large_file() signature might default my_temp_dir.
Consider renaming it to simply temp_dir.
For compatibility with /usr/bin/sort, os.environ['TMPDIR'] would be a fair default.
Consider renaming starting_file to in_file (or input_file).
Docstrings start with an English sentence, e.g. &quot;Splits a file into pieces.&quot;
If the intent is &quot;...into sorted pieces,&quot; then say so,
and make the function name match.
Splitting a file is by itself a valuable service, even without sorting.
Please say &quot;a list of&quot; rather than &quot;a list with all&quot;.
It appears liste_file has a typo, plus it should simply be files.
Simplify line_holder to lines.
algorithm

line budget vs RAM budget
chunking
loop style

You impose a million-line max on each piece.
But the true goal was to cap RAM consumption,
which is indirectly related through the average chars-per-line
for a given input file.
Consider adding up line lengths
rather than incrementing by one for each line.
Related to this, the line-by-line iteration is on the slow side,
especially for input files comprised of short lines.
Consider doing one or more binary .read()'s,
and then reading until newline so only complete lines go to the outfile.
(Or scan backwards through the chunk to find a newline,
then seek() to that position before issuing the next read.)
The if line_holder: line is a code smell,
it suggests that you didn't quite find a form of while loop
that matched your application.
Perhaps a boolean done flag would help to
remove the copy-n-pasted 2nd chunk of code.
If for some reason you feel it still needs to remain,
then definitely extract both copies into a small helper method.
DRY: https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
This is correct, but weird:
            if cpt % max_line == 0:
                cpt = 0

If line number cpt (don't know what that stands for) hits limit,
we reset the line number and emit a chunk.
Computing modulo % is more expensive than a comparison &gt;.
Usually modulo would be used if we're not going to reset the line number.
Three comments about the lambda:

This is the first we've heard about the input file being a .tsv. Improve the docstring.
The lambda is fine, but consider breaking it out as a named function.
The .split() copies out the entire line, but it only needs to copy as far as first TAB.

We evaluate merged() for side effects,
so we're looking for a verb name rather than an adjective.
Just call it merge(), or perhaps external_merge().
Consider defaulting col=0 in the signature.
Each docstring should start with an English sentence.
The comment &quot;being minimal the script will fail if one column is shorter than this value&quot; is accurate.
But, better to rewrite as a pre-condition on valid inputs:
&quot;must exist in each input row.&quot;
    my_heap = []

Yes, it is your heap.
But that's not what is interesting about it.
Better to just call it heap.
    for elem in liste_file:

This would more naturally be: for file in files:
You used a hardcoded column zero in split_large_file(),
but now you are apparently processing unsorted input
since col might be positive.
Please assign sentinel = sys.maxsize,
if that is how you're trying to use it.
Or at least add a comment.
(It is 0x7FFFFFFFFFFFFFFF, is that what you want?)
The break apparently should be raising a fatal exception instead,
since the input file apparently is not allowed to contain that sentinel
(not allowed to contain arbitrary contents).
The references to minimal[0], [1], and [2] are obscure.
Please use tuple unpack to put them in val, line, file_temp
or similarly informative variables.
The early explicit .remove() is fine.
If you had specified delete=True (or let it default)
the temp files would be deleted when the interpreter does a normal exit.
Depending on platform, defaulting tmp_dir to something like /tmp
might be more appropriate than to CWD (which might be unwritable).
Overall, looks pretty good, pretty readable.
One can always improve.