Basic cryptography algorithm
I'm no cryptography guru, so my comments will aim at the code in itself, not the algorithms.

Message.h / Message.cpp:


There doesn't seem to be a need to include &lt;iostream&gt; nor &lt;fstream&gt; in the header file. Avoid importing dependencies that you don't use. The cost of an include is in compile-time. One too many big projects suffer with long compile times due to poor management of include files.
Keep your parameter names in function/method prototypes. This will self document your code. Take this constructor for instance:


Message(const std::string&amp;, const int&amp;);



Impossible to tell which parameter is doing what without consulting the implementation.
cryptoContainer is a "type alias", nevertheless, it names a type. Your naming convention for types is PascalCase, so CryptoContainer would be more self-consistent.
writeOriginalMessage is currently returning a meaningless integer value (always zero). It could very well return nothing (void). If there is a possibility of failure, then return a boolean true or false.
Still talking about writeOriginalMessage and writeCryptedMessage, both have a quite similar loop inside:


for (auto it = m_originalContent.begin(); it != m_originalContent.end(); it++)



You can significantly shorten them by using a range based foreach loop:

for (const auto &amp; item : container)
{
    stream &lt;&lt; item;
}


Notice the reference &amp;. Care should be taken to avoid copying things in this style of iteration since the default in C++ is always a copy.
Writing void in the parameter list of a C++ function that takes no parameters (as in getOriginalMessage(void)) is a C-ish style. C++ does not require that; () is just as good. So avoid the unnecessary verbosity.
virtual destructors are only necessary when your class is meant to be inherited from. In this particular code, that doesn't seem to be the case with Message. If you did that to allow users of your code to inherit from the class, I would advise against, since Composition is usually much more elegant and with less coupling. You should remove virtual from the destructor declaration and perhaps even mark your class final. While your are at it, them make the protected section private and throw the destructor away, since it is empty.
I see that you have a couple places with names not in English, while the bigger whole is all in that language. It would be better to keep things uniform, so replace things like texte and clef with the proper English terms.
In functions/methods that return void, no need to explicitly return at the end. E.g.: setOriginalMessage and setCryptedMessage.
Careful with noisy/meaningless comments. // constructors and // destructor are self evident.


Chiffre.h / Chiffre.cpp:


Again, unnecessary includes: you don't need &lt;vector&gt; in the header file.
Also, the reasons for Chiffre having a virtual destructor are not clear. If you don't have inheritance, you shouldn't be making it virtual.
The empty constructor is also unnecessary. Leave it out if you have no manual initialization to perform.