Les architectures réseau de type Software Defined Networking (SDN) ont été introduites dans l'objectif de proposer un contrôle centralisé par un contrôleur. Une conséquence de cette centralisation est le fait qu'une seule entité soit en charge du contrôle. Par conséquent, cela fait du contrôleur la cible privilégiée en cas d'attaque sur une architecture SDN. Une telle attaque permettrait à un attaquant d'avoir une vue globale sur le réseau, mettre en place un contrôle visant à dégrader le service, etc. De plus, une simple défaillance du contrôleur est également une menace sur le réseau puisque cela le priverait de contrôle. On peut trouver dans la littérature que l'architecture multicontrôleur a été introduite afin de renforcer le plan de contrôle contre ces menaces. Cependant, une telle architecture amène de nouvelles spécificités et pour assurer la cohérence entre les contrôleurs, une interface de communication entre eux est nécessaire. Cette interface constitue une menace pour la sécurité puisqu'un attaquant peut propager des informations malveillantes et erronées sur le réseau aux autres contrôleurs. Dans cet objectif, ces travaux visent à introduire une architecture multicontrôleur sans interface de communication entre eux. Cette architecture est composée d'un contrôleur nominal en charge du calcul du plan de données et un second en charge de la détection d'anomalies dans les décisions prises par le contrôleur principal. Pour cela, le comportement de l'activité de la commande a été formalisé sous la forme d'un extit{template} : en réponse à une requête des infrastructures réseau, le contrôleur doit mettre en place un plan de données dans un certain intervalle de temps. Pour être considéré comme anormal, le contrôleur doit respecter ça, mais ce n'est pas suffisant. Il faut ensuite vérifier le contenu du plan de données et pour cela des propriétés structurelles définissant ce qu'on considère comme étant un plan de données cohérent sont introduites. Ces propriétés sont nécessaires, mais pas suffisantes et en conséquence une méthode de détection a été proposée selon le type de contrôle considéré : déterministe ou non. Dans le cas déterministe, on estime les variables internes du contrôleur à partir des décisions cohérentes prises et observées. Ensuite, il faut vérifier que le contrôleur ne se contredit pas du fait de l'hypothèse de déterminisme. Cette méthode n'est donc plus applicable au cas non déterministe et on propose d'établir un score de vraisemblance aux décisions prises par le contrôleur. Ce score est établi suivant une approche multi critères dont le choix des critères dépend du cas d'application. Ici, deux critères ont étés proposés : vérification que l'impact des décisions prises par le contrôleur est vraisemblable et vérification que la séquence des décisions prises par le contrôleur est vraisemblable. Cette méthode est évaluée selon deux types de métriques : réactivité et nombre de bonnes décisions prises par le contrôleur (précision et rappel) sur divers cas d'étude. En conclusion, les performances montrent que les méthodes proposées sont applicables, mais présentent des limites. De plus, ces travaux posent les fondements d'une méthode de détection, mais chaque application est propre au cas d'étude considéré.