Inviting users to use AND/OR () type logic using query_string may seem appealing but the query parser lacks the syntax to express nested clauses and even if it did I'm not sure most end users would know how to use it or want to.
It's a potentially dangerous combination to offer users the tools to write formal Boolean logic but with no clear way of expressing the logic about which values they are ANDing etc.
The problem is the user needs to be explicit about which context they are AND or ORing in. Are they ANDing terms that come from the same nested object or are they properties they hope to find in different objects.
query_string does not let them express that context.
If your query is word AND excel I assume the user is finding a candidate with both of these skills. That would be easily achieved having a "flat" mapping and not using nested at all.
The reason I expect you opted for nested mappings in your original example is that at some point someone wanted to query for secteurName: qwr AND secteurExp:3. In this case nested mappings are necessary to avoid the "cross-matching" problem of flattening all skills into a single Lucene document.
However - the 2 queries word AND excel and qwr AND 3 have very different assumptions about how matching should work. The first assumes you are querying across nested docs and the second assumes you are querying inside nested docs and there is no way for the user to control which behaviour they require using the query_string query parser.
If your users are only doing cross-object ANDing like the word AND excel example then consider using copy_to to put content in the root or drop the use of nested if you have no other need for it.
Maybe run both? You can of course have a bool should array with the user query in a nested context and also as a flattened non-nested one. The doc that matches the nested clause will also match the flattened clause and come top. The doc that matches only the flattened clause should not rank as highly.