Abstract factory pattern for a system modelisation
First of all: You got it nearly right.

One thing in your implementation deviates from the standard implementation:

@Override
public Composant getComposant(String composant) {
    if(composant.equalsIgnoreCase("Boutton")) return new Boutton();
    else if(composant.equalsIgnoreCase("Menu")) return new Menu();
    return null;
}


You parameterize your factory methods with a string. Don't do that in this case. Passing a parameter to a factory may be possible but the products should be "strong" related to each other. Everybody who wants to know what your factory can produce should see it by the method signatures provided by the abstract factory and not guess (or read in the documentation... urgh). If you want to produce two different items, create another factory method. For a factory "FactoryX" this should look like this:

@Override
public Button createBoutton() {
    return new BouttonX();
}

@Override
public Menu createMenu() {
    return new MenuX();
}


One other thing: the abstract Composant-class is irrelevant to the abstract factory in your case as far as I see. Furthermore it will bind you to a set of methods that "Menus" and "Bouttons" have in common. This would hinder you to configure special properties of "Bouttons" and "Menus". The two types may of course stay derived from Composant.

I thought about it a little bit when the use of parameters in the factory pattern may be appropriate. In the following example (in pseudo code) a LabelField or a LabelArea is returned which depends on the size of the given text.

@Override
public AbstractLabel getAbstractLabel(String text) {
    if (text.length &gt; 120) {
        return new LabelArea(text); // multi line presentation
    } else {
        return new LabelField(text) // single line presentation
    }
}


The parameter is not technically connected to the return value but semantically. You can see the strong relationship between those return values. They were built to present text.