The issue is that the console uses different code pages than the rest of the system. For example normally Windows systems set up for the Americas and Western Europe use CP1252, but the console in those regions uses CP437 or CP850.
You can either set the console output code page to match the encoding you're using or you can convert the strings to match the console's output code page.
Set the console output codepage:
SetConsoleOutputCP(GetACP()); // GetACP() returns the system codepage.
std::cout << "La chaîne qui correspond au code \"TEST_CODE\" n'a pas été trouvée à l'aide locale \"fr\".";
Or one of many ways to convert between encodings (this one requires VS2010 or greater):
#include <codecvt> // for wstring_convert
#include <locale> // for codecvt_byname
#include <iostream>
int main() {
typedef std::codecvt_byname<wchar_t,char,std::mbstate_t> codecvt;
// the following relies on non-standard behavior, codecvt destructors are supposed to be protected and unusable here, but VC++ doesn't complain.
std::wstring_convert<codecvt> cp1252(new codecvt(".1252"));
std::wstring_convert<codecvt> cp850(new codecvt(".850"));
std::cout << cp850.to_bytes(cp1252.from_bytes("...été trouvée à...\n")).c_str();
}
The latter example assumes you do in fact need to convert between 1252 and 850. You should probably use the function GetOEMCP() to figure out the actual target code page, and the source codepage actually depends on what you use for the source code rather than on the result of GetACP() on the machine running the program.
Also note that this program relies on something not guaranteed by the standard: that the wchar_t encoding be shared between locales. This is true on most platforms—usually some Unicode encoding is used for wchar_t in all locales—but not all.
Ideally you could just use UTF-8 everywhere and the following would work fine, as it does on other platforms these days:
#include <iostream>
int main() {
std::cout << "La chaîne qui correspond au code \"TEST_CODE\" n'a pas été trouvée à l'aide locale \"fr\".\n";
}
Unfortunately Windows can't support UTF-8 this way without either abandoning UTF-16 as the wchar_t encoding and adopting a 4 byte wchar_t, or violating requirements of the standard and breaking standard conforming programs.